Hi,
If this is repeatable, it is probably worth reporting as a bug on the bug
tracker. See -
http://docs.geoserver.org/latest/en/user/introduction/gettinginvolved.html#bug-tracking
Ideally with some sample data if it is data specific.
Regards,
Jonathan
On 20 September 2013 14:53, anwa <[email protected]> wrote:
> Hello GeoServer-Mailing List, we are experiencing problems that appear to
> be memory leaks of GeoServer when trying to serve tiles from a JPEG
> WorldImage (TIF WorldImages seem to be fine). The error is easily
> reproducable (see steps below) and leads to the Tomcat container's Heap
> space (PS Old Gen and PS Eden, to be exact) to be filled up to 99 %, making
> Tomcat unresponsive and preventing GeoServer from rendering any more new
> tiles. Our System: * Tomcat: Apache Tomcat/7.0.40 - Heap space for PS Old
> Gen is a whopping 965 MB max, PS Eden Space is 381 MB max * JVM: Oracle
> Corporation: 1.7.0_25 (Java HotSpot(TM) 64-Bit Server VM) * OS: Linux
> 2.6.32-358.11.1.el6.x86_64 (64 Bit) * GeoServer: 2.4.0 (but happens with
> 2.2.2 and 2.3.2 as well), no native JAI Steps to Reproduce the Problem *
> Setup: GeoServer in a Tomcat container. * You need a WorldImage store for a
> JPEG file in GeoServer. ---> In [GEOSERVER_DATA_DIR]/coverages/img_sample
> you can find the files Pk50095.tfw, Pk50095.tif and Pk50095.prj . Open the
> tif with an image program of your choice and save it as Pk50095.jpeg in a
> new folder. Make a copy of Pk50095.tfw, move it to the new folder and
> rename it to Pk50095.jgw . Now you can either copy the .prj-File into the
> new folder or you can leave it out (this file does not seem to influence
> the problematic behaviour). Once you have done this, add a new WorldImage
> Store to your GeoServer (URL is the path to the new Pk50095.jpeg) and
> publish the layer. If you left out the .prj-File, you have to set the
> layer's declared SRS to EPSG:32633, set "Force declared" and hit "Compute
> from native bounds"). * Open your new layer with the GeoServer
> LayerPreview. Set the Tiling option to "tiled" and start zooming, panning
> etc. - just create lots of requests for tiles for the new layer. * If you
> watch your Tomcat's heap now (with the Tomcat Manager Web App, for
> instance), you should see PS Old Gen filling up until it reaches 99 %. PS
> Eden Space will then fill up, too. Tomcat will show several threads with
> requests for the specific layer "hanging" in state "Service" for very long
> times (up to more than 30 minutes in one of our tests). * Finally,
> OutOfMemory errors will show up in the GeoServer log and Tomcat may become
> unresponsive (see attached detailed log
> file<http://osgeo-org.1560.x6.nabble.com/file/n5078884/geoserver.log.demo>,
> look for the following errors): ERROR [geoserver.ows] -
> java.lang.OutOfMemoryError: Java heap space ERROR [geoserver.ows] -
> java.lang.RuntimeException: javax.imageio.IIOException: Improper call to
> JPEG library in state 202 ERROR [geotools.map] - Call MapContent dispose()
> to prevent memory leaks ERROR [geoserver.ows] - java.lang.OutOfMemoryError:
> GC overhead limit exceeded Our Concrete Error Situation * We have a
> WorldImage store for a JPEG file (so we have a JPEG and a related JGW) in
> GeoServer and publish the JPEG as a layer with EPSG:31467. * Whenever tiles
> for this layer get rendered, we can see (via the Tomcat Manager Web App)
> its PS Old Gen Heap space continuosly filling up as described above. Tomcat
> will become sluggish/unresponsive. Requests for cached tiles sometimes go
> through apparently unaffected, but new tiles will not be rendered. * In
> order to get a responsive Tomcat again, we restart it. Now the heap will be
> (almost) empty, but it will fill up again if the JPEG WorldImage-Layer gets
> rendered. * We saved our original JPEG file as a TIF file and created a TGW
> file containing the same contents as the original JGW file. If we add this
> TIF file as a WorldImage Store and publish it as a layer with EPSG:31467,
> rendering seems to work perfectly fine and the heap space does not appear
> to be filling up. * Note: The original JPEG/JGW files have been in use with
> GeoServer since 2011 and we cannot remember having experienced these
> problems before! We noticed them just now after moving the GeoServer to the
> current system (see above). The previous system was: Linux 2.6.18-348.el5
> i386, Apache Tomcat/6.0.26, JVM Sun Microsystems Inc.: 1.6.0_20 (Java
> HotSpot(TM) Client VM), GeoServer 2.2.2 . The old Tomcat doesn't show
> detailed information about its heap memory in the Tomcat Manager Web App,
> but we can see that we only had a total available memory of 742.43 MB (much
> less than on the new system), and we can play around with our JPEG
> WorldImage layer without any problems... Ideas * It seems to be related
> to the format of the WorldImage - TIFs seem to be fine, JPEGs fill up the
> heap space. * Is the JPEG image repeatedly loaded into heap memory for
> rendering, and this memory is never released (and therefore cannot be
> Garbage Collected)? * We tried setting the recommended options for the JVM
> (-Xmx256M -Xms48m), but that only made the problem worse because we had
> less heap than before, so it fills up faster. ;-) * It seems to be related
> to us moving our GeoServer to our new system - 64 bit architecture? Newer
> JVM? Newer Tomcat? Now, as described we found a workaround (using a TIF
> WorldImage instead of the original JPEG WorldImage), but this behaviour
> does not seem to be right. We are aware that using a JPEG or PNG as a
> WorldImage isn't optimal, but it used to work fine (for our needs) until we
> moved to the current system... I could not find anything in JIRA about
> this, is this a bug in GeoServer?
> ------------------------------
> View this message in context: Memory Leaks during rendering of JPEG
> WorldImage (Java heap space filling
> up)<http://osgeo-org.1560.x6.nabble.com/Memory-Leaks-during-rendering-of-JPEG-WorldImage-Java-heap-space-filling-up-tp5078884.html>
> Sent from the GeoServer - User mailing list
> archive<http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html>at
> Nabble.com.
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Geoserver-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
--
This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in error
please notify the sender immediately. All email traffic sent to or from us,
including without limitation all GCSX traffic, may be subject to recording
and/or monitoring in accordance with relevant legislation.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
