Hi all,
Running the wcs cite tests I ran into problems with some of the coverage tests. Many of the tests don't return an image back because they run out of memory.
Digging a little deeper it seems that the threads that are prefetching the tiles for the image are running out of memory. In some cases this leads to the image being returned ok, other times it results in a timeout waiting for the thread...
Increasing memory to 128M makes the problem go away. I get the same result in java 4 as in java 5
Here is an example stack trace.
org.vfny.geoserver.wcs.WcsException: java.lang.RuntimeException: Waiting thread received a null tile.
at org.vfny.geoserver.wcs.WcsExceptionHandler.newServiceException(WcsExceptionHandler.java:73)
at org.vfny.geoserver.servlets.AbstractService.sendError(AbstractService.java:850)
at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:610)
at org.vfny.geoserver.servlets.AbstractService.doGet(AbstractService.java:315)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:192)
at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.java:52)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:347)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1050)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:103)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:354)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:269)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:687)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:208)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.lang.RuntimeException: Waiting thread received a null tile.
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:963)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
at javax.media.jai.PlanarImage.getExtendedData(PlanarImage.java:2440)
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1255)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
at javax.media.jai.RenderedOp.getData(RenderedOp.java:2276)
at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.writeTile(TIFFImageWriter.java:1754)
at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.write(TIFFImageWriter.java:2686)
at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.write(TIFFImageWriter.java:2417)
at org.geotools.gce.geotiff.GeoTiffWriter.writeImage(GeoTiffWriter.java:376)
at org.geotools.gce.geotiff.GeoTiffWriter.write(GeoTiffWriter.java:203)
at org.vfny.geoserver.wcs.responses.coverage.GeoTIFFCoverageResponseDelegate.encode(GeoTIFFCoverageResponseDelegate.java:95)
at org.vfny.geoserver.wcs.responses.CoverageResponse.writeTo(CoverageResponse.java:169)
at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:582)
... 27 more
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin,
is this problem coming out asking every kind of Coverage, or just the GTOPO one? In the second case, the problem could be the GTOPO plugin, which we know it requires a lot of memory… maybe we can use a different configuration for the cite tests, using stable plugin for CoverageStores, like World Images, GeoTIFFs or ASCII-grids.
On 3/22/07, Justin Deoliveira <jdeolive@anonymised.com > wrote:
Hi all,
Running the wcs cite tests I ran into problems with some of the coverage
tests. Many of the tests don’t return an image back because they run out
of memory.
Digging a little deeper it seems that the threads that are prefetching
the tiles for the image are running out of memory. In some cases this
leads to the image being returned ok, other times it results in a
timeout waiting for the thread…
Increasing memory to 128M makes the problem go away. I get the same
result in java 4 as in java 5
Here is an example stack trace.
org.vfny.geoserver.wcs.WcsException: java.lang.RuntimeException: Waiting
thread received a null tile.
at
org.vfny.geoserver.wcs.WcsExceptionHandler.newServiceException (WcsExceptionHandler.java:73)
at
org.vfny.geoserver.servlets.AbstractService.sendError(AbstractService.java:850)
at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:610)
at
org.vfny.geoserver.servlets.AbstractService.doGet(AbstractService.java:315)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:192)
at
org.geoserver.request.Dispatcher.handleRequestInternal (Dispatcher.java:52)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle (SimpleControllerHandlerAdapter.java:44)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
at
org.springframework.web.servlet.DispatcherServlet.doService (DispatcherServlet.java:625)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java :347)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :445)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1050)
at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java :103)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:354)
at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java:226)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle (Server.java:269)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:687)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:208)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.lang.RuntimeException : Waiting thread received a null tile.
at
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:963)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.getData (PlanarImage.java:2085)
at javax.media.jai.PlanarImage.getExtendedData(PlanarImage.java:2440)
at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1255)
at
com.sun.media.jai.util.SunTileScheduler.scheduleTile (SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
at javax.media.jai.RenderedOp.getData(RenderedOp.java :2276)
at
com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.writeTile(TIFFImageWriter.java:1754)
at
com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.write(TIFFImageWriter.java:2686)
at
com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.write(TIFFImageWriter.java:2417)
at
org.geotools.gce.geotiff.GeoTiffWriter.writeImage(GeoTiffWriter.java:376)
at org.geotools.gce.geotiff.GeoTiffWriter.write (GeoTiffWriter.java:203)
at
org.vfny.geoserver.wcs.responses.coverage.GeoTIFFCoverageResponseDelegate.encode(GeoTIFFCoverageResponseDelegate.java:95)
at
org.vfny.geoserver.wcs.responses.CoverageResponse.writeTo (CoverageResponse.java:169)
at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:582)
… 27 more
-Justin
–
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net 's Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions
http://www.geo-solutions.it
Alessio Fabiani ha scritto:
Justin,
is this problem coming out asking every kind of Coverage, or just the GTOPO one? In the second case, the problem could be the GTOPO plugin, which we know it requires a lot of memory... maybe we can use a different configuration for the cite tests, using stable plugin for CoverageStores, like World Images, GeoTIFFs or ASCII-grids.
Yeah. Or maybe it's just the case of stating that WCS tests need to
be run with 128MB heap, that is, it's something that is by design, and
not an error, a regression. At the moment, we don't know if the problem
falls in the first or second category.
Alessio, what amount of memory did you use to run WCS tests? And Brent?
Cheers
Andrea
I used 512 Mb
On 3/22/07, Andrea Aime <aaime@anonymised.com> wrote:
Alessio Fabiani ha scritto:
Justin,
is this problem coming out asking every kind of Coverage, or just the
GTOPO one? In the second case, the problem could be the GTOPO plugin,
which we know it requires a lot of memory… maybe we can use a
different configuration for the cite tests, using stable plugin for
CoverageStores, like World Images, GeoTIFFs or ASCII-grids.
Yeah. Or maybe it’s just the case of stating that WCS tests need to
be run with 128MB heap, that is, it’s something that is by design, and
not an error, a regression. At the moment, we don’t know if the problem
falls in the first or second category.
Alessio, what amount of memory did you use to run WCS tests? And Brent?
Cheers
Andrea
–
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions
http://www.geo-solutions.it
Justin Deoliveira ha scritto:
Hi all,
Running the wcs cite tests I ran into problems with some of the coverage tests. Many of the tests don't return an image back because they run out of memory.
Guess what? It was my patch for geos-928 that did it.
I forgot to check if raster2model was null in abstractgridcoverageReader2d, and thus it was returning the full resolution image for all formats, since the only one that sets raster2model is the world image one.
Fixed, not all 88 tests pass (I was getting 59 because I did not check
the last two boxes in the wcs test config page).
Sorry for the inconvenience 
Cheers
Andrea
I have the habit of running with 512MB for the tests.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Alessio Fabiani ha scritto:
Justin,
is this problem coming out asking every kind of Coverage, or just the GTOPO one? In the second case, the problem could be the GTOPO plugin, which we know it requires a lot of memory... maybe we can use a different configuration for the cite tests, using stable plugin for CoverageStores, like World Images, GeoTIFFs or ASCII-grids.
Yeah. Or maybe it's just the case of stating that WCS tests need to
be run with 128MB heap, that is, it's something that is by design, and
not an error, a regression. At the moment, we don't know if the problem
falls in the first or second category.
Alessio, what amount of memory did you use to run WCS tests? And Brent?
Cheers
Andrea