One of the line styles does have a dash array, but none of the polygons. Curious that it only impacts at it this kind of scale.
Could you point me at a description of the bug, so I can see if the problem also exists with the IBM JDK? Thanks On 5 August 2010 18:22, Andrea Aime <[email protected]> wrote: > Rob ha scritto: > > I'm seeing a serious problem with my geoserver install, where it is >> crashing the system it is running on, following certain types of WMS >> requests. >> >> Given the fact that I am probably the only person on the list running >> GeoServer (v2.0.0) under WebSphere App Server, using IBM Java, on AIX, I am >> not expecting anybody to point me in the direction of a silver bullet. >> However, if someone could confirm my theory as to what is happening that is >> causing the issue in the first place, it might help. I'll try and talk >> through an example, and my hypothesis - made with no knowledge of the >> geoserver code whatsoever, I hasten to add! :) >> >> >> FOR AN EXAMPLE WAYWARD REQUEST >> >> I am rendering some vector data stored in Oracle Spatial. This data is >> quite detailed, and from the geoserver debug logs, I can identify the exact >> SQL used. I can run the SQL in sqlplus and the records return pretty much >> instantaneously. There are eight polygons, and eight lines. The lines and >> polygons have between 50 and 300 vertices, and are styled in different ways. >> The MBR for these records is approx 2km by 1.5km. >> >> These records render beautifully, and quickly (1-2 seconds) at 1:2000. [To >> my simple mind, this suggests that the geometries are valid, and that the >> styling is OK. I remember seeing an issue with symbols at these kind of >> scales causing problems, but none of these records would be styled using >> symbols. Basic lines and fills only] >> >> As I zoom in (and in, and in) the rendering starts to take more time each >> time, until I'm at something like 1:50. Rendering is now taking 20 seconds. >> If I zoom in until I'm at 1:2 or 1:1, I can see the memory on the machine >> be eaten up, until WebSphere starts paging like crazy and eventually the >> machine hangs. >> >> My theory is that GeoServer is trying to create an image at the same scale >> as the target bbox, but containing the entire geometries pulled back from >> Oracle. So if I request a 600x600 pixel image at 1:1 scale, it tries to >> build an internal image that would contain the 2km x 1.5km - i.e., a (600 x >> 2000=1200000) x (600 x 1500=900000) image, before it would cut out the >> 600x600 bbox of interest. >> >> Is this how it works? >> >> GeoServer does have some WMS resource consumption limits that I can >> configure, and I have these currently set to >> >> Max rendering memory - 73728 KB (up from 64Mb, as I was seeing some >> OutOfMemory issues on something else) >> Max rendering time - 20s (down from 60s - see below) >> Max rendering errors - 100 (down from 1000) >> >> Changing the max rendering time seems to have helped, as GeoServer cant >> eat all the available memory and pagespace inside 20 seconds (so far anyway >> - touch wood!), but I would have hoped that if it was a memory issue, that >> the limit stated here would be adhered to. I'd rather GeoServer barfed an >> OutOfMemory error than it taking down my entire server. Should this limit >> have stopped the problem? >> >> The next thing for me to try (within GeoServer at least) is to try and set >> up some MinScaleDenominators in the SLDs so that these features aren't >> displayed beyond 1:10. >> >> Are there any other suggestions on how to make this work/fallover >> gracefully? >> > > My guess is that you're using a dash array on the lines of those > polygons. There is a well known java2d bug that makes the rendering > bomb out. > > We could clip the line before passing it to the renderer, but doing it > properly is not easy and so far nobody every had spare time to work on > it, nor paid time. > > Cheers > Andrea > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. >
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
