Testing GeoServer 1.7.5, I found a strange behaviour in WMS: when the requested bounding box is little (10 to 50 meters) in comparison to the requested featuretype/s bbox (some kilometer to hundreds of kilometers). Memory used starts to grow during rendering until I get an OutOfMemory. The same featuretypes were rendering perfectly (with low memory usage) on 1.7.3a.
Maybe the bug is related to GEOS-3162. It seems that when a shape is much bigger than the requested area it cannot be rendered anymore using limited resources.
To reproduce the bug try the following request:
http://localhost:8080/geoserver/wms?bbox=-100,35,-99.999,35.0001&styles=population&Format=image/png&request=GetMap&layers=topp:states&width=550&height=250&srs=EPSG:4326
WARNING: it should crash GeoServer!
Thanks in advance,
Mauro Bartolomeoli
Mauro Bartolomeoli ha scritto:
Testing GeoServer 1.7.5, I found a strange behaviour in WMS: when the requested bounding box is little (10 to 50 meters) in comparison to the requested featuretype/s bbox (some kilometer to hundreds of kilometers). Memory used starts to grow during rendering until I get an OutOfMemory. The same featuretypes were rendering perfectly (with low memory usage) on 1.7.3a.
Maybe the bug is related to GEOS-3162. It seems that when a shape is much bigger than the requested area it cannot be rendered anymore using limited resources.
To reproduce the bug try the following request:
http://localhost:8080/geoserver/wms?bbox=-100,35,-99.999,35.0001&styles=population&Format=image/png&request=GetMap&layers=topp:states&width=550&height=250&srs=EPSG:4326
Is this happening also if you don't provide any stroke in the polygon
symbolizers?
(sorry I did not test that myself, I'm on the hook for some other work)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Mauro Bartolomeoli ha scritto:
Testing GeoServer 1.7.5, I found a strange behaviour in WMS: when the requested bounding box is little (10 to 50 meters) in comparison to the requested featuretype/s bbox (some kilometer to hundreds of kilometers). Memory used starts to grow during rendering until I get an OutOfMemory. The same featuretypes were rendering perfectly (with low memory usage) on 1.7.3a.
Maybe the bug is related to GEOS-3162. It seems that when a shape is much bigger than the requested area it cannot be rendered anymore using limited resources.
To reproduce the bug try the following request:
http://localhost:8080/geoserver/wms?bbox=-100,35,-99.999,35.0001&styles=population&Format=image/png&request=GetMap&layers=topp:states&width=550&height=250&srs=EPSG:4326
Is this happening also if you don't provide any stroke in the polygon
symbolizers?
Good question! Without a stroke GeoServer is behaving nicely! So... do you have any hints on why this is happening and where in the code I could investigate further?
Thanks,
Mauro
Mauro Bartolomeoli ha scritto:
Is this happening also if you don't provide any stroke in the polygon
symbolizers?
Good question! Without a stroke GeoServer is behaving nicely! So... do you have any hints on why this is happening and where in the code I could investigate further?
My guess is that it is related to http://jira.codehaus.org/browse/GEOT-2538
... but afaik the gt 2.5.6 release used to make 1.7.5 should have
had that fixed... evidently not, since I can reproduce the problem
you reported on current 1.7.x as well 
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
Mauro Bartolomeoli ha scritto:
Is this happening also if you don't provide any stroke in the polygon
symbolizers?
Good question! Without a stroke GeoServer is behaving nicely! So... do you have any hints on why this is happening and where in the code I could investigate further?
My guess is that it is related to http://jira.codehaus.org/browse/GEOT-2538
... but afaik the gt 2.5.6 release used to make 1.7.5 should have
had that fixed... evidently not, since I can reproduce the problem
you reported on current 1.7.x as well
Darn, it turns out I failed to commit on bit of the patch and the problem was not really solved.
So yeah, we have 1.7.4 and 1.7.5 going OOM if a large polygon is painted
so that it is a lot bigger than the current screen area.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Glad to know you have a simple solution... do you think I can find it on a nightly build soon?
Thanks,
Mauro
Andrea Aime wrote:
Andrea Aime ha scritto:
Mauro Bartolomeoli ha scritto:
Is this happening also if you don't provide any stroke in the polygon
symbolizers?
Good question! Without a stroke GeoServer is behaving nicely! So... do you have any hints on why this is happening and where in the code I could investigate further?
My guess is that it is related to http://jira.codehaus.org/browse/GEOT-2538
... but afaik the gt 2.5.6 release used to make 1.7.5 should have
had that fixed... evidently not, since I can reproduce the problem
you reported on current 1.7.x as well
Darn, it turns out I failed to commit on bit of the patch and the problem was not really solved.
So yeah, we have 1.7.4 and 1.7.5 going OOM if a large polygon is painted
so that it is a lot bigger than the current screen area.
Cheers
Andrea
Mauro Bartolomeoli ha scritto:
Glad to know you have a simple solution... do you think I can find it on a nightly build soon?
Tomorrow's, or if you can't wait, just build gt2 and gs 1.7.x right
now, the patch is already commited.
Looking forward to see if the patch fixed it for you
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.