Re: [Geoserver-users] GeoServer crashing system
Rob ha scritto: > Removing the dashes element of the style does seem to have improved > performance, and no longer brings the app to its knees. > > Unfortunately, some styles do need to be dashed - for example showing > tunnels that go underground. > > > Tunnel > Tunnel > 1500 > > > TYPE > Tunnel > > > > > #33 > 0.2 > > > > > > One workaround would be for me to use a dash above a certain scale, and > no dash below it. Any SLD gurus advise on whether this can be done > within a single rule, or whether I need a separate rule for each > undashed style? You need a separate rule. Or you need to modify the rendering code so that it clips the lines to the current rendering area before passing them to java2d... which is really not as trivial as it seems, you have to take into consideration the stroke widths (the line might be sitting outside parallel to the map border but the stroke be so think that it actually shows up) and avoid using JTS intersection functions because they are just too slow to be usable during rendering... I know how to fix that, but unfortunately have no spare time to dedicate to this issue... can you open a ticket on jira.codehaus.org? 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 Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] GeoServer crashing system
Removing the dashes element of the style does seem to have improved performance, and no longer brings the app to its knees. Unfortunately, some styles do need to be dashed - for example showing tunnels that go underground. Tunnel Tunnel 1500 TYPE Tunnel #33 0.2 One workaround would be for me to use a dash above a certain scale, and no dash below it. Any SLD gurus advise on whether this can be done within a single rule, or whether I need a separate rule for each undashed style? Thanks Rob On 6 August 2010 10:38, Andrea Aime wrote: > Rob ha scritto: > > One of the line styles does have a dash array, but none of the polygons. >> > > Ok, try to remove the layers that have lines with dash arrays from your > request. Does it still crash? > And if you just use the layers with lines and dashes, what happens? > > > Curious that it only impacts at it this kind of scale. >> > > The Sun bug starts using more memory the more you zoom in. > Not sure if the IBM JDKC is affected by the same issue, but it's worth > having a look > > > Could you point me at a description of the bug, so I can see if the >> problem also exists with the IBM JDK? >> > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6568969 > > > 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 Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] GeoServer crashing system
Rob ha scritto: > One of the line styles does have a dash array, but none of the polygons. Ok, try to remove the layers that have lines with dash arrays from your request. Does it still crash? And if you just use the layers with lines and dashes, what happens? > Curious that it only impacts at it this kind of scale. The Sun bug starts using more memory the more you zoom in. Not sure if the IBM JDKC is affected by the same issue, but it's worth having a look > Could you point me at a description of the bug, so I can see if the > problem also exists with the IBM JDK? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6568969 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 Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] GeoServer crashing system
Geoserver/Websphere crashes the whole AIX Box ???. I have never seen that, unbelievable. Since 10 years I am working with Websphere I always got a heapdump (Linux/zOs, Linux/ppc, Linux/Intel, AIX). The only exception is if the disk partition is full. I assume this is not the case. No hints in native stderr either ? What about trying geoserver 2.0.2 ? What version of Websphere are you using (6.0 with sdk 5 or 7.0 with sdk 6) ? Quoting Rob : > Hi Christian > > Oh, that it were so simple! When WebSphere crashes, it takes out the whole > server, and I don't believe it has the time to create a core dump file. I > have tried killing it before it gets too far down this process with a kill > -3 ( as I can see the memory usage and paging quickly climb on topas), > but although the coredump file looked OK to me, neither tool recognised it > as such. > > I have to say, I think this is a WebSphere issue as well as a GeoServer > issue, and am trying to document the bug as well as I can in order to raise > it with IBM. I don't believe that a java app should be capable of bringing > down a server, and I'm sure its just a case of tuning the WAS properly. > > Thanks > > Rob > > > On 6 August 2010 08:55, wrote: > >> Hi, I have a similar configuration using AIX, Linux/ppc, IBM sdk, openjdk , >> DB2 and Websphere or jetty. >> >> To make it short. If your Websphere crashes it creates an heapdump, >> composed of 2 or 3 files. You should find these files in your profile >> directory (something like /opt/IBM/Webspere/AppServer/profiles/server1). >> >> There is an IBM tool >> http://www.alphaworks.ibm.com/tech/heaproots >> >> for analyzing the dump. For large heapdumps , please dont use the GUI >> version, otherwise the utility would create an heapdump for itself :-(. >> Command Line operation is needed. >> >> Within the last 3 years, this utility helps me to solve any problem >> concerning memory problems and finding the code causing these problems. >> >> I would recommend you to invest some time, I am sure this is not the last >> heapdump you have to study. Believe me, it is the best way to find the >> problem. >> >> If you have questions, please ask, I will support you. >> >> I can also analyze your heapdump, but this requires at minimum one day and >> this is part of my commercial support for customers. >> >> Hope this helps >> >> >> >> >> >> >> >> >> >> >> Quoting Andrea Aime : >> >> 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=120) x (600 x 1500=90) 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 s
Re: [Geoserver-users] GeoServer crashing system
Hi Christian Oh, that it were so simple! When WebSphere crashes, it takes out the whole server, and I don't believe it has the time to create a core dump file. I have tried killing it before it gets too far down this process with a kill -3 ( as I can see the memory usage and paging quickly climb on topas), but although the coredump file looked OK to me, neither tool recognised it as such. I have to say, I think this is a WebSphere issue as well as a GeoServer issue, and am trying to document the bug as well as I can in order to raise it with IBM. I don't believe that a java app should be capable of bringing down a server, and I'm sure its just a case of tuning the WAS properly. Thanks Rob On 6 August 2010 08:55, wrote: > Hi, I have a similar configuration using AIX, Linux/ppc, IBM sdk, openjdk , > DB2 and Websphere or jetty. > > To make it short. If your Websphere crashes it creates an heapdump, > composed of 2 or 3 files. You should find these files in your profile > directory (something like /opt/IBM/Webspere/AppServer/profiles/server1). > > There is an IBM tool > http://www.alphaworks.ibm.com/tech/heaproots > > for analyzing the dump. For large heapdumps , please dont use the GUI > version, otherwise the utility would create an heapdump for itself :-(. > Command Line operation is needed. > > Within the last 3 years, this utility helps me to solve any problem > concerning memory problems and finding the code causing these problems. > > I would recommend you to invest some time, I am sure this is not the last > heapdump you have to study. Believe me, it is the best way to find the > problem. > > If you have questions, please ask, I will support you. > > I can also analyze your heapdump, but this requires at minimum one day and > this is part of my commercial support for customers. > > Hope this helps > > > > > > > > > > > Quoting Andrea Aime : > > 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=120) x (600 x 1500=90) 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 p
Re: [Geoserver-users] GeoServer crashing system
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 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=120) x (600 x 1500=90) 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 Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] GeoServer crashing system
Hi, I have a similar configuration using AIX, Linux/ppc, IBM sdk, openjdk , DB2 and Websphere or jetty. To make it short. If your Websphere crashes it creates an heapdump, composed of 2 or 3 files. You should find these files in your profile directory (something like /opt/IBM/Webspere/AppServer/profiles/server1). There is an IBM tool http://www.alphaworks.ibm.com/tech/heaproots for analyzing the dump. For large heapdumps , please dont use the GUI version, otherwise the utility would create an heapdump for itself :-(. Command Line operation is needed. Within the last 3 years, this utility helps me to solve any problem concerning memory problems and finding the code causing these problems. I would recommend you to invest some time, I am sure this is not the last heapdump you have to study. Believe me, it is the best way to find the problem. If you have questions, please ask, I will support you. I can also analyze your heapdump, but this requires at minimum one day and this is part of my commercial support for customers. Hope this helps Quoting Andrea Aime : > 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=120) x (600 x 1500=90) 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. > > -- > The Palm PDK Hot Apps Program offers develop
Re: [Geoserver-users] GeoServer crashing system
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=120) x (600 x 1500=90) 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. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] GeoServer crashing system
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=120) x (600 x 1500=90) 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? Any wise words gratefully received, as always. Rob -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
