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 spaceERROR [geoserver.ows] -
java.lang.RuntimeException: javax.imageio.IIOException: Improper call to
JPEG library in state 202ERROR [geotools.map] - Call MapContent dispose() to
prevent memory leaksERROR [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:
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 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
