[Geoserver-users] Overworked CPU .. GeoServer & Oracle

Tom_JDi_Solutions · July 26, 2007, 8:11am

Hi all,

Please see below an email I sent to the uDig list which it appears may be more relevant to this list. In summary the issue is as follows:

I’m running uDig 1.1-RC10 Geoserver 1.5.? and Oracle 10.0.2.3 on my laptop (2GB RAM, Intel core 2 duo CPU) and am testing viewing mastermap for an entire UK county via WFS. I have 3 layers loaded in uDig, topographic line, which is all the lines on the map (there are 4.8 million in the complete table but I’m only looking at one village in uDig at the moment, the points which I extracted from topographic line (21 million points in the layer) and a data layer which compared to the other two is inconsequential.

Initially when the layers are loaded it takes a minute or so for them to be rendered but once they’re there I can pan around and zoom with reasonable speed, there’s usually a second or so delay before a redraw but nothing prohibitive. The problem is that once uDig has loaded all the layers the CPU continues to work hard for up to 15 minutes or so after the layers have been loaded, with no panning or zooming, in fact with no user interaction at all. Closing uDig does not return the CPU to normal levels, closing Geoserver immediately does so it looks like Geoserver and Oracle are the culprits. What’s going on here?

Tom

---------- Forwarded message ----------
From: Jody Garnett < jgarnett@anonymised.com>
Date: Jul 26, 2007 1:51 AM
Subject: [udig-devel] Overworked CPU … GeoServer
To: User-friendly Desktop Internet GIS < udig-devel@anonymised.com>

Thanks David for the helpful hint; indeed lets send this on to GeoServer
along with instructions on how to reproduce the problem.
Jody

I don’t have a profiler and I wouldn’t know where to start so if
that’s reqd someone will have to guide me through it, however I tried
David’s suggestion and loaded uDig up with all my layers. Once they
had loaded I left it for a couple of minutes and as usual the CPU
continued to work hard. I then closed uDig and the CPU continued to
work hard. I left it for another couple of minutes or so and then
shut down Geoserver at which point the CPU immediately dropped back to
normal. That suggests to me that the problem is with Geoserver and
Oracle and not uDig so if you agree I’ll forward this to the geoserver
mailing list to see what they think?

Tom

On 7/25/07, David Zwiers < david.zwiers@anonymised.com
mailto:[david.zwiers@anonymised.com](mailto:david.zwiers@anonymised.com)> wrote:

Rather than using a profiler (can be hard to setup because eclipse
is an exe and there are two pids here), you may be able to
issolate the issue by replicating, then killing uDig but not
geoserver. If the CPU returns to normal, I would be inclined to
think this is an issue between uDig and GeoServer (having little
or nothing todo with Oracle).

My 2 cents
David

On 7/25/07, Jody Garnett < jgarnett@anonymised.com
mailto:[jgarnett@anonymised.com](mailto:jgarnett@anonymised.com)> wrote:

Tom (JDi Solutions) wrote:

but the CPU is maxed out for 15 minutes or so after the layer
has been
rendered, without me zooming or panning. Why? Presumably
uDig only
requests the data it needs to render the area of the layer
shown on
screen, so what is the CPU working on for the next 15 minutes
while I
do nothing?
You are correct that sounds wrong

Sounds like we need to get you to run in a profiler so we can
tell what
the matter is (sigh). Do you have a profiler available?

Jody

User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net < http://udig.refractions.net/>
http://lists.refractions.net/mailman/listinfo/udig-devel
<http://lists.refractions.net/mailman/listinfo/udig-devel >

User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
< http://lists.refractions.net/mailman/listinfo/udig-devel >

User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

gershwinou · July 26, 2007, 8:25am

I already used geoserver to serve millions of points from postgis with no problem…
What can happen is that you eventually overload your RAM and then geoserver try to deal with the data (well java actually). Can you check you RAM load (on windows: right click on the taskbar->task manager; on linux, issue in the command line “top”) when you retrieve all the data.
Second possibility, sometimes, you hit the maximum java heap and geoserver can output millions of lines in the logs (saying you overhead the heap space) and can become mad in this case… increasing java heap space can help (adding or changing -Xmx1024m in the java call, look at your startup script)

Hope it can help

Gersh

On 26/07/07, Tom (JDi Solutions) <tom.dean@anonymised.com > wrote:

Hi all,

Please see below an email I sent to the uDig list which it appears may be more relevant to this list. In summary the issue is as follows:

I’m running uDig 1.1-RC10 Geoserver 1.5.? and Oracle 10.0.2.3 on my laptop (2GB RAM, Intel core 2 duo CPU) and am testing viewing mastermap for an entire UK county via WFS. I have 3 layers loaded in uDig, topographic line, which is all the lines on the map (there are 4.8 million in the complete table but I’m only looking at one village in uDig at the moment, the points which I extracted from topographic line (21 million points in the layer) and a data layer which compared to the other two is inconsequential.

Initially when the layers are loaded it takes a minute or so for them to be rendered but once they’re there I can pan around and zoom with reasonable speed, there’s usually a second or so delay before a redraw but nothing prohibitive. The problem is that once uDig has loaded all the layers the CPU continues to work hard for up to 15 minutes or so after the layers have been loaded, with no panning or zooming, in fact with no user interaction at all. Closing uDig does not return the CPU to normal levels, closing Geoserver immediately does so it looks like Geoserver and Oracle are the culprits. What’s going on here?

Tom

Tom_JDi_Solutions · July 26, 2007, 9:18am

Thanks for your response,

I’m on Windows and there’s plenty of spare physical RAM. With all running I’ve never seen the system using more than about 1.4GB so there should be 600MB free.

Geoserver does not appear to be spewing loads of messages, certainly in the command window it remains calm. How do I increase java heap space exactly?

cheers,

Tom

On 7/26/07, gershwinou <gershwinou@anonymised.com> wrote:

I already used geoserver to serve millions of points from postgis with no problem…
What can happen is that you eventually overload your RAM and then geoserver try to deal with the data (well java actually). Can you check you RAM load (on windows: right click on the taskbar->task manager; on linux, issue in the command line “top”) when you retrieve all the data.
Second possibility, sometimes, you hit the maximum java heap and geoserver can output millions of lines in the logs (saying you overhead the heap space) and can become mad in this case… increasing java heap space can help (adding or changing -Xmx1024m in the java call, look at your startup script)

Hope it can help

Gersh

On 26/07/07, Tom (JDi Solutions) < tom.dean@anonymised.com > wrote:

Hi all,

Please see below an email I sent to the uDig list which it appears may be more relevant to this list. In summary the issue is as follows:

I’m running uDig 1.1-RC10 Geoserver 1.5.? and Oracle 10.0.2.3 on my laptop (2GB RAM, Intel core 2 duo CPU) and am testing viewing mastermap for an entire UK county via WFS. I have 3 layers loaded in uDig, topographic line, which is all the lines on the map (there are 4.8 million in the complete table but I’m only looking at one village in uDig at the moment, the points which I extracted from topographic line (21 million points in the layer) and a data layer which compared to the other two is inconsequential.

Initially when the layers are loaded it takes a minute or so for them to be rendered but once they’re there I can pan around and zoom with reasonable speed, there’s usually a second or so delay before a redraw but nothing prohibitive. The problem is that once uDig has loaded all the layers the CPU continues to work hard for up to 15 minutes or so after the layers have been loaded, with no panning or zooming, in fact with no user interaction at all. Closing uDig does not return the CPU to normal levels, closing Geoserver immediately does so it looks like Geoserver and Oracle are the culprits. What’s going on here?

Tom

gershwinou · July 26, 2007, 9:28am

in your startup script (startup.bat), you should have a line at the end like (geoserver 1.6beta2):
:runJava
cd %GEOSERVER_HOME%
%RUN_JAVA% -DGEOSERVER_DATA_DIR=“%GEOSERVER_DATA_DIR%” -Dorg.geotools.referencing.forceXY=true -jar %GEOSERVER_HOME%\start.jar

change it adding -Xmx1024m before -jar:
:runJava
cd %GEOSERVER_HOME%
%RUN_JAVA% -DGEOSERVER_DATA_DIR=“%GEOSERVER_DATA_DIR%” -Dorg.geotools.referencing.forceXY=true -Xmx1024m -jar %GEOSERVER_HOME%\start.jar

Cheers

On 26/07/07, Tom (JDi Solutions) <tom.dean@anonymised.com > wrote:

Thanks for your response,

I’m on Windows and there’s plenty of spare physical RAM. With all running I’ve never seen the system using more than about 1.4GB so there should be 600MB free.

Geoserver does not appear to be spewing loads of messages, certainly in the command window it remains calm. How do I increase java heap space exactly?

cheers,

Tom

On 7/26/07, gershwinou < gershwinou@anonymised.com> wrote:

I already used geoserver to serve millions of points from postgis with no problem…
What can happen is that you eventually overload your RAM and then geoserver try to deal with the data (well java actually). Can you check you RAM load (on windows: right click on the taskbar->task manager; on linux, issue in the command line “top”) when you retrieve all the data.
Second possibility, sometimes, you hit the maximum java heap and geoserver can output millions of lines in the logs (saying you overhead the heap space) and can become mad in this case… increasing java heap space can help (adding or changing -Xmx1024m in the java call, look at your startup script)

Hope it can help

Gersh

On 26/07/07, Tom (JDi Solutions) < tom.dean@anonymised.com > wrote:

Hi all,

Please see below an email I sent to the uDig list which it appears may be more relevant to this list. In summary the issue is as follows:

I’m running uDig 1.1-RC10 Geoserver 1.5.? and Oracle 10.0.2.3 on my laptop (2GB RAM, Intel core 2 duo CPU) and am testing viewing mastermap for an entire UK county via WFS. I have 3 layers loaded in uDig, topographic line, which is all the lines on the map (there are 4.8 million in the complete table but I’m only looking at one village in uDig at the moment, the points which I extracted from topographic line (21 million points in the layer) and a data layer which compared to the other two is inconsequential.

Initially when the layers are loaded it takes a minute or so for them to be rendered but once they’re there I can pan around and zoom with reasonable speed, there’s usually a second or so delay before a redraw but nothing prohibitive. The problem is that once uDig has loaded all the layers the CPU continues to work hard for up to 15 minutes or so after the layers have been loaded, with no panning or zooming, in fact with no user interaction at all. Closing uDig does not return the CPU to normal levels, closing Geoserver immediately does so it looks like Geoserver and Oracle are the culprits. What’s going on here?

Tom

Tom_JDi_Solutions · July 26, 2007, 9:48am

That doesn’t appear to have had any impact. Java.exe (Geoserver [uDig is in the list as javaw.exe]) is still using between 60-70% of the CPU and Oracle 10-20%. Neither is doing anything other than serving these maps for uDig and I haven’t touched uDig since it rendered the maps in the first place.

java.exe’s memory usage is no different to before too at about 79MB and not edging upwards at all.

5 minutes later and the CPU usage and memory usage remain consistent. Closing uDig has no effect. Closing Geoserver (which hasn’t reported anything since it rendered the maps initially) returns the CPU to normal.

Below is the last few things reported by Geoserver, it includes an error but since that error was produced, the layers were rendered, seemingly correctly in uDig.

As soon as I had finished writing that Geoserver also reported the following:

674998 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675029 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL

All the layers loading in uDig are wfs layers so no idea why these reports all refer to wms?

reported before uDig finished rendering the layers:

22.5629144635 258722.4962559061, 535093.9880412493 258722.4962559061, 535093.988
0412493 258497.79722530386, 534722.5629144635 258497.79722530386)) ] AND [[[[[[[
geometryType([GEOMETRY]) = Point ] OR [ geometryType([GEOMETRY]) = MultiPoint ]
] OR [ geometryType([GEOMETRY]) = LineString ]] OR [ geometryType([GEOMETRY]) =
LinearRing ]] OR [ geometryType([GEOMETRY]) = MultiLineString ]] OR [ geometryTy
pe([GEOMETRY]) = Polygon ]] OR [ geometryType([GEOMETRY]) = MultiPolygon ]]]
[properties: GEOMETRY]

137720 [btpool0-2] INFO org.vfny.geoserver.servlets - handling request: Describe
FeatureType Request [outputFormat: XMLSCHEMA [feature types: sam:TOPO_LINE_POINT
S]
137720 [btpool0-6] INFO org.vfny.geoserver.servlets - OutputStream was successfu
lly aborted.
137720 [btpool0-6] ERROR org.vfny.geoserver.servlets - Service exception occurre
d
org.vfny.geoserver.ServiceException : null error:Translator error
at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:221)
at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureRespo
nse.java:127)
at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
at org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.ja
va:447)
at org.geoserver.request.Dispatcher.post(Dispatcher.java :301)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(Dispatch
erServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(Frame
workServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost (FrameworkServ
let.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service (HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (Servlet
Handler.java:1050)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCha
racterEncodingFilter.java:103)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:3
54)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
27)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle (HandlerCollection.
java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
at org.mortbay.jetty.Server.handle(Server.java:269)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
n.java:701)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at org.mortbay.jetty.nio.HttpChannelEndPoint.run (HttpChannelEndPoint.jav
a:270)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: javax.xml.transform.TransformerException: Translator error
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:130)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
… 32 more
Caused by: java.lang.RuntimeException: Error reading Features
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse (Tra
nsformerBase.java:625)
at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.j
ava:293)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:126)
… 34 more
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
… 39 more
Caused by: org.mortbay.jetty.EofException
at org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
at org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
… 40 more
137720 [btpool0-2] INFO org.vfny.geoserver.servlets - Service handled
137736 [btpool0-6] WARN org.vfny.geoserver.responses - encountered error: null e
rror:Translator error
StackTrace: javax.xml.transform.TransformerException: Translator error
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:130)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo (FeatureRespo
nse.java:127)
at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
at org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.ja
va:447)
at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch (Dispatch
erServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(Frame
workServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServ
let.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java :709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1050)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter (SetCha
racterEncodingFilter.java:103)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
54)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java :6
27)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
at org.mortbay.jetty.Server.handle(Server.java:269)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
at org.mortbay.jetty.HttpConnection$RequestHandler.content (HttpConnectio
n.java:701)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.jav
a:270)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: java.lang.RuntimeException: Error reading Features
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(Tra
nsformerBase.java:625)
at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.j
ava:293)
at org.geotools.xml.transform.TransformerBase.transform (TransformerBase.
java:126)
… 34 more
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
… 39 more
Caused by: org.mortbay.jetty.EofException
at org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
at org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
… 40 more

java.lang.RuntimeException: Error reading Features
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(Tra
nsformerBase.java:625)
at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.j
ava:293)
at org.geotools.xml.transform.TransformerBase.transform (TransformerBase.
java:126)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureRespo
nse.java:127)
at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
at org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.ja
va:447)
at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch (Dispatch
erServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(Frame
workServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServ
let.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java :709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1050)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter (SetCha
racterEncodingFilter.java:103)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
54)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java :6
27)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
at org.mortbay.jetty.Server.handle(Server.java:269)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
at org.mortbay.jetty.HttpConnection$RequestHandler.content (HttpConnectio
n.java:701)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.jav
a:270)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
… 39 more
Caused by: org.mortbay.jetty.EofException
at org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
at org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
… 40 more

137767 [btpool0-6] INFO org.vfny.geoserver.servlets - Stream abruptly closed by
client, response aborted
140048 [btpool0-4] INFO org.vfny.geoserver.servlets - Service handled

On 7/26/07, gershwinou <gershwinou@anonymised.com> wrote:

in your startup script (startup.bat), you should have a line at the end like (geoserver 1.6beta2):
:runJava
cd %GEOSERVER_HOME%
%RUN_JAVA% -DGEOSERVER_DATA_DIR=“%GEOSERVER_DATA_DIR%” -Dorg.geotools.referencing.forceXY=true -jar %GEOSERVER_HOME%\start.jar

change it adding -Xmx1024m before -jar:
:runJava
cd %GEOSERVER_HOME%
%RUN_JAVA% -DGEOSERVER_DATA_DIR=“%GEOSERVER_DATA_DIR%” -Dorg.geotools.referencing.forceXY=true -Xmx1024m -jar %GEOSERVER_HOME%\start.jar

Cheers

On 26/07/07, Tom (JDi Solutions) < tom.dean@anonymised.com > wrote:

Thanks for your response,

I’m on Windows and there’s plenty of spare physical RAM. With all running I’ve never seen the system using more than about 1.4GB so there should be 600MB free.

Geoserver does not appear to be spewing loads of messages, certainly in the command window it remains calm. How do I increase java heap space exactly?

cheers,

Tom

On 7/26/07, gershwinou < gershwinou@anonymised.com> wrote:

I already used geoserver to serve millions of points from postgis with no problem…
What can happen is that you eventually overload your RAM and then geoserver try to deal with the data (well java actually). Can you check you RAM load (on windows: right click on the taskbar->task manager; on linux, issue in the command line “top”) when you retrieve all the data.
Second possibility, sometimes, you hit the maximum java heap and geoserver can output millions of lines in the logs (saying you overhead the heap space) and can become mad in this case… increasing java heap space can help (adding or changing -Xmx1024m in the java call, look at your startup script)

Hope it can help

Gersh

On 26/07/07, Tom (JDi Solutions) < tom.dean@anonymised.com > wrote:

Hi all,

Please see below an email I sent to the uDig list which it appears may be more relevant to this list. In summary the issue is as follows:

I’m running uDig 1.1-RC10 Geoserver 1.5.? and Oracle 10.0.2.3 on my laptop (2GB RAM, Intel core 2 duo CPU) and am testing viewing mastermap for an entire UK county via WFS. I have 3 layers loaded in uDig, topographic line, which is all the lines on the map (there are 4.8 million in the complete table but I’m only looking at one village in uDig at the moment, the points which I extracted from topographic line (21 million points in the layer) and a data layer which compared to the other two is inconsequential.

Initially when the layers are loaded it takes a minute or so for them to be rendered but once they’re there I can pan around and zoom with reasonable speed, there’s usually a second or so delay before a redraw but nothing prohibitive. The problem is that once uDig has loaded all the layers the CPU continues to work hard for up to 15 minutes or so after the layers have been loaded, with no panning or zooming, in fact with no user interaction at all. Closing uDig does not return the CPU to normal levels, closing Geoserver immediately does so it looks like Geoserver and Oracle are the culprits. What’s going on here?

Tom

Justin_Deoliveira · July 26, 2007, 3:41pm

Tough problem to diagnose... Oracle has not received the amount of qa and performance testing that Postgis has (due to lack of a module maintainer) so I am not all that surprised...

Are you trying to render the entire layers at once. Or are you zooming into a specific location. I seem to remember their being an issue with our renderer and rendering many that many features onto a relatively small image... i could be wrong though... If so it could be that requests are timing out and the processes that are handling them are not dying properly... Not sure i am kind of reaching here.

Andrea will probably have a better idea of how to diagnose the problem... he is the expert when it comes to performance around these parts.

-Justin

Tom (JDi Solutions) wrote:

That doesn't appear to have had any impact. Java.exe (Geoserver [uDig is in the list as javaw.exe]) is still using between 60-70% of the CPU and Oracle 10-20%. Neither is doing anything other than serving these maps for uDig and I haven't touched uDig since it rendered the maps in the first place.

java.exe's memory usage is no different to before too at about 79MB and not edging upwards at all.

5 minutes later and the CPU usage and memory usage remain consistent. Closing uDig has no effect. Closing Geoserver (which hasn't reported anything since it rendered the maps initially) returns the CPU to normal.

Below is the last few things reported by Geoserver, it includes an error but since that error was produced, the layers were rendered, seemingly correctly in uDig.

As soon as I had finished writing that Geoserver also reported the following:

674998 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
675029 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers - Adding GetLeg
endGraphic call as LegendURL

All the layers loading in uDig are wfs layers so no idea why these reports all refer to wms?

reported before uDig finished rendering the layers:

22.5629144635 258722.4962559061, 535093.9880412493 258722.4962559061, 535093.988
0412493 258497.79722530386, 534722.5629144635 258497.79722530386)) ] AND [[[[[[[
geometryType([GEOMETRY]) = Point ] OR [ geometryType([GEOMETRY]) = MultiPoint ]
] OR [ geometryType([GEOMETRY]) = LineString ]] OR [ geometryType([GEOMETRY]) =
LinearRing ]] OR [ geometryType([GEOMETRY]) = MultiLineString ]] OR [ geometryTy
pe([GEOMETRY]) = Polygon ]] OR [ geometryType([GEOMETRY]) = MultiPolygon ]]]
   [properties: GEOMETRY]

137720 [btpool0-2] INFO org.vfny.geoserver.servlets - handling request: Describe
FeatureType Request [outputFormat: XMLSCHEMA [feature types: sam:TOPO_LINE_POINT
S]
137720 [btpool0-6] INFO org.vfny.geoserver.servlets - OutputStream was successfu
lly aborted.
137720 [btpool0-6] ERROR org.vfny.geoserver.servlets - Service exception occurre
d
org.vfny.geoserver.ServiceException : null error:Translator error
        at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:221)
        at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureRespo
nse.java:127)
        at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
        at org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.ja
va:447)
        at org.geoserver.request.Dispatcher.post(Dispatcher.java :301)
        at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
        at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
        at org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
        at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(Dispatch
erServlet.java:684)
        at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(Frame
workServlet.java:392)
        at org.springframework.web.servlet.FrameworkServlet.doPost (FrameworkServ
let.java:357)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
        at javax.servlet.http.HttpServlet.service (HttpServlet.java:802)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (Servlet
Handler.java:1050)
        at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCha
racterEncodingFilter.java:103)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
        at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:3
54)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
27)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
        at org.mortbay.jetty.handler.HandlerCollection.handle (HandlerCollection.
java:123)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
        at org.mortbay.jetty.Server.handle(Server.java:269)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
n.java:701)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
        at org.mortbay.jetty.nio.HttpChannelEndPoint.run (HttpChannelEndPoint.jav
a:270)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: javax.xml.transform.TransformerException: Translator error
        at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:130)
        at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
        at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
        ... 32 more
Caused by: java.lang.RuntimeException: Error reading Features
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
        at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse (Tra
nsformerBase.java:625)
        at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
        at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.j
ava:293)
        at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:126)
        ... 34 more
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
        ... 39 more
Caused by: org.mortbay.jetty.EofException
        at org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
        at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
        at org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
        ... 40 more
137720 [btpool0-2] INFO org.vfny.geoserver.servlets - Service handled
137736 [btpool0-6] WARN org.vfny.geoserver.responses - encountered error: null e
rror:Translator error
StackTrace: javax.xml.transform.TransformerException: Translator error
        at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:130)
        at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
        at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
        at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo (FeatureRespo
nse.java:127)
        at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
        at org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.ja
va:447)
        at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
        at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
        at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
        at org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
        at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch (Dispatch
erServlet.java:684)
        at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(Frame
workServlet.java:392)
        at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServ
let.java:357)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java :709)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1050)
        at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter (SetCha
racterEncodingFilter.java:103)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
54)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java :6
27)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:123)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
        at org.mortbay.jetty.Server.handle(Server.java:269)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content (HttpConnectio
n.java:701)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
        at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:199)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
        at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.jav
a:270)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: java.lang.RuntimeException: Error reading Features
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
        at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(Tra
nsformerBase.java:625)
        at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
        at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.j
ava:293)
        at org.geotools.xml.transform.TransformerBase.transform (TransformerBase.
java:126)
        ... 34 more
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
        ... 39 more
Caused by: org.mortbay.jetty.EofException
        at org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
        at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
        at org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
        ... 40 more
---------
java.lang.RuntimeException: Error reading Features
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
        at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(Tra
nsformerBase.java:625)
        at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
        at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.j
ava:293)
        at org.geotools.xml.transform.TransformerBase.transform (TransformerBase.
java:126)
        at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
        at org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
        at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureRespo
nse.java:127)
        at org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
        at org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.ja
va:447)
        at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
        at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
        at org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
        at org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
        at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch (Dispatch
erServlet.java:684)
        at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(Frame
workServlet.java:392)
        at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServ
let.java:357)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java :709)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1050)
        at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter (SetCha
racterEncodingFilter.java:103)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
54)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java :6
27)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:123)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
        at org.mortbay.jetty.Server.handle(Server.java:269)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content (HttpConnectio
n.java:701)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
        at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:199)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
        at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.jav
a:270)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
        ... 39 more
Caused by: org.mortbay.jetty.EofException
        at org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
        at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
        at org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
        at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
        ... 40 more

137767 [btpool0-6] INFO org.vfny.geoserver.servlets - Stream abruptly closed by
client, response aborted
140048 [btpool0-4] INFO org.vfny.geoserver.servlets - Service handled

On 7/26/07, *gershwinou* <gershwinou@anonymised.com <mailto:gershwinou@anonymised.com>> wrote:

    in your startup script (startup.bat), you should have a line at the
    end like (geoserver 1.6beta2):
    :runJava
      cd %GEOSERVER_HOME%
      %RUN_JAVA% -DGEOSERVER_DATA_DIR="%GEOSERVER_DATA_DIR%"
    -Dorg.geotools.referencing.forceXY=true -jar %GEOSERVER_HOME%\start.jar

    change it adding -Xmx1024m before -jar:
    :runJava
      cd %GEOSERVER_HOME%
      %RUN_JAVA% -DGEOSERVER_DATA_DIR="%GEOSERVER_DATA_DIR%"
    -Dorg.geotools.referencing.forceXY=true -Xmx1024m -jar
    %GEOSERVER_HOME%\start.jar

    Cheers

    On 26/07/07, *Tom (JDi Solutions)* < tom.dean@anonymised.com
    <mailto:tom.dean@anonymised.com>> wrote:

        Thanks for your response,

        I'm on Windows and there's plenty of spare physical RAM. With
        all running I've never seen the system using more than about
        1.4GB so there should be 600MB free.

        Geoserver does not appear to be spewing loads of messages,
        certainly in the command window it remains calm. How do I
        increase java heap space exactly?

        cheers,

        Tom

        On 7/26/07, *gershwinou* < gershwinou@anonymised.com
        <mailto:gershwinou@anonymised.com>> wrote:

            I already used geoserver to serve millions of points from
            postgis with no problem...
            What can happen is that you eventually overload your RAM and
            then geoserver try to deal with the data (well java
            actually). Can you check you RAM load (on windows: right
            click on the taskbar->task manager; on linux, issue in the
            command line "top") when you retrieve all the data.
            Second possibility, sometimes, you hit the maximum java heap
            and geoserver can output millions of lines in the logs
            (saying you overhead the heap space) and can become mad in
            this case... increasing java heap space can help (adding or
            changing -Xmx1024m in the java call, look at your startup
            script)

            Hope it can help

            Gersh

            On 26/07/07, *Tom (JDi Solutions)* <
            tom.dean@anonymised.com
            <mailto:tom.dean@anonymised.com> > wrote:

                Hi all,

                Please see below an email I sent to the uDig list which
                it appears may be more relevant to this list. In
                summary the issue is as follows:

                I'm running uDig 1.1-RC10 Geoserver 1.5.? and Oracle
                10.0.2.3 <http://10.0.2.3/> on my laptop (2GB RAM, Intel
                core 2 duo CPU) and am testing viewing mastermap for an
                entire UK county via WFS. I have 3 layers loaded in
                uDig, topographic line, which is all the lines on the
                map (there are 4.8 million in the complete table but I'm
                only looking at one village in uDig at the moment, the
                points which I extracted from topographic line (21
                million points in the layer) and a data layer which
                compared to the other two is inconsequential.

                Initially when the layers are loaded it takes a minute
                or so for them to be rendered but once they're there I
                can pan around and zoom with reasonable speed, there's
                usually a second or so delay before a redraw but nothing
                prohibitive. The problem is that once uDig has loaded
                all the layers the CPU continues to work hard for up to
                15 minutes or so after the layers have been loaded, with
                no panning or zooming, in fact with no user interaction
                at all. Closing uDig does not return the CPU to normal
                levels, closing Geoserver immediately does so it looks
                like Geoserver and Oracle are the culprits. What's
                going on here?

                Tom

!DSPAM:4007,46a86e11276932085621377!

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

!DSPAM:4007,46a86e11276932085621377!

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46a86e11276932085621377!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Tom_JDi_Solutions · July 26, 2007, 6:08pm

Justin, thanks for your thoughts. I’m zoomed in to a specific area of the map, perhaps less than 1/400th of the total dataset and as I said, the layer seems to be rendered correctly and completely but geoserver and oracle continue to work hard.

Andrea, any thoughts? I could supply the data for you assuming it remains confidential (it’s protected by strict copyright) but obviously it would be a large download, the export will prob be a gig for topo_line. Alternatively if there’s anything relatively simple that I can do from here I’m more than happy to give it a go. You’ve got my IM details. I’d really appreciate some help with this and I’m sure I won’t be the only one to benefit if this issue can be resolved.

cheers,

Tom

On 7/26/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Tough problem to diagnose… Oracle has not received the amount of qa
and performance testing that Postgis has (due to lack of a module
maintainer) so I am not all that surprised…

Are you trying to render the entire layers at once. Or are you zooming
into a specific location. I seem to remember their being an issue with
our renderer and rendering many that many features onto a relatively
small image… i could be wrong though… If so it could be that
requests are timing out and the processes that are handling them are not
dying properly… Not sure i am kind of reaching here.

Andrea will probably have a better idea of how to diagnose the
problem… he is the expert when it comes to performance around these parts.

-Justin

Tom (JDi Solutions) wrote:

That doesn’t appear to have had any impact. Java.exe (Geoserver [uDig
is in the list as javaw.exe]) is still using between 60-70% of the CPU
and Oracle 10-20%. Neither is doing anything other than serving these
maps for uDig and I haven’t touched uDig since it rendered the maps in
the first place.

java.exe’s memory usage is no different to before too at about 79MB and
not edging upwards at all.

5 minutes later and the CPU usage and memory usage remain consistent.
Closing uDig has no effect. Closing Geoserver (which hasn’t reported
anything since it rendered the maps initially) returns the CPU to normal.

Below is the last few things reported by Geoserver, it includes an error
but since that error was produced, the layers were rendered, seemingly
correctly in uDig.

As soon as I had finished writing that Geoserver also reported the
following:

674998 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675014 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
675029 [btpool0-5] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725125 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL
725140 [btpool0-3] INFO org.vfny.geoserver.wms.responses.helpers -
Adding GetLeg
endGraphic call as LegendURL

All the layers loading in uDig are wfs layers so no idea why these
reports all refer to wms?

reported before uDig finished rendering the layers:

22.5629144635 258722.4962559061, 535093.9880412493 258722.4962559061,
535093.988
0412493 258497.79722530386 , 534722.5629144635 258497.79722530386)) ] AND
[[[[[[[
geometryType([GEOMETRY]) = Point ] OR [ geometryType([GEOMETRY]) =
MultiPoint ]
] OR [ geometryType([GEOMETRY]) = LineString ]] OR [
geometryType([GEOMETRY]) =
LinearRing ]] OR [ geometryType([GEOMETRY]) = MultiLineString ]] OR [
geometryTy
pe([GEOMETRY]) = Polygon ]] OR [ geometryType([GEOMETRY]) = MultiPolygon ]]]
[properties: GEOMETRY]

137720 [btpool0-2] INFO org.vfny.geoserver.servlets - handling request:
Describe
FeatureType Request [outputFormat: XMLSCHEMA [feature types:
sam:TOPO_LINE_POINT
S]
137720 [btpool0-6] INFO org.vfny.geoserver.servlets - OutputStream was
successfu
lly aborted.
137720 [btpool0-6] ERROR org.vfny.geoserver.servlets - Service exception
occurre
d
org.vfny.geoserver.ServiceException : null error:Translator error
at
org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:221)
at
org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo (FeatureRespo
nse.java:127)
at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
at
org.vfny.geoserver.servlets.AbstractService.doPost (AbstractService.ja
va:447)
at org.geoserver.request.Dispatcher.post(Dispatcher.java :301)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
at
org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch (Dispatch
erServlet.java:684)
at
org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
at
org.springframework.web.servlet.FrameworkServlet.processRequest (Frame
workServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost
(FrameworkServ
let.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java :709)
at javax.servlet.http.HttpServlet.service (HttpServlet.java:802)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter
(Servlet
Handler.java:1050)
at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCha
racterEncodingFilter.java:103)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (Servlet
Handler.java:1041)
at org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:3
54)
at
org.mortbay.jetty.servlet.SessionHandler.handle( SessionHandler.java:2
26)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
27)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHand
lerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle
(HandlerCollection.
java:123)
at
org.mortbay.jetty.handler.HandlerWrapper.handle (HandlerWrapper.java:1
41)
at org.mortbay.jetty.Server.handle(Server.java:269)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
n.java:701)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at org.mortbay.jetty.nio.HttpChannelEndPoint.run
(HttpChannelEndPoint.jav
a:270)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: javax.xml.transform.TransformerException: Translator error
at
org.geotools.xml.transform.TransformerBase.transform (TransformerBase.
java:130)
at
org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
at
org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode (G
ML2FeatureResponseDelegate.java:212)
… 32 more
Caused by: java.lang.RuntimeException: Error reading Features
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
at
org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse (Tra
nsformerBase.java:625)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
at
org.geotools.xml.transform.TransformerBase$Task.run (TransformerBase.j
ava:293)
at
org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:126)
… 34 more
Caused by: java.lang.RuntimeException : org.mortbay.jetty.EofException
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
… 39 more
Caused by: org.mortbay.jetty.EofException
at
org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
at
org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
… 40 more
137720 [btpool0-2] INFO org.vfny.geoserver.servlets - Service handled
137736 [btpool0-6] WARN org.vfny.geoserver.responses - encountered
error: null e
rror:Translator error
StackTrace: javax.xml.transform.TransformerException : Translator error
at
org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:130)
at
org.geotools.xml.transform.TransformerBase.transform(TransformerBase.
java:105)
at
org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo
(FeatureRespo
nse.java:127)
at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
at
org.vfny.geoserver.servlets.AbstractService.doPost (AbstractService.ja
va:447)
at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
at
org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch
(Dispatch
erServlet.java:684)
at
org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
at
org.springframework.web.servlet.FrameworkServlet.processRequest (Frame
workServlet.java:392)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServ
let.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java :709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1050)
at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter (SetCha
racterEncodingFilter.java :103)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java :3
54)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java :6
27)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:123)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
at org.mortbay.jetty.Server.handle(Server.java:269)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
at org.mortbay.jetty.HttpConnection$RequestHandler.content
(HttpConnectio
n.java:701)
at org.mortbay.jetty.HttpParser.parseNext (HttpParser.java:617)
at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at
org.mortbay.jetty.nio.HttpChannelEndPoint.run (HttpChannelEndPoint.jav
a:270)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: java.lang.RuntimeException: Error reading Features
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
at
org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(Tra
nsformerBase.java:625)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform (Transf
ormerIdentityImpl.java:484)
at
org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.j
ava:293)
at org.geotools.xml.transform.TransformerBase.transform
(TransformerBase.
java:126)
… 34 more
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
… 39 more
Caused by: org.mortbay.jetty.EofException
at
org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
at
org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
… 40 more

java.lang.RuntimeException: Error reading Features
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:444)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
at
org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse (Tra
nsformerBase.java:625)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transf
ormerIdentityImpl.java:484)
at
org.geotools.xml.transform.TransformerBase$Task.run (TransformerBase.j
ava:293)
at org.geotools.xml.transform.TransformerBase.transform
(TransformerBase.
java:126)
at
org.geotools.xml.transform.TransformerBase.transform (TransformerBase.
java:105)
at
org.vfny.geoserver.wfs.responses.GML2FeatureResponseDelegate.encode(G
ML2FeatureResponseDelegate.java:212)
at
org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo (FeatureRespo
nse.java:127)
at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService
.java:582)
at
org.vfny.geoserver.servlets.AbstractService.doPost (AbstractService.ja
va:447)
at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:181)
at
org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.jav
a:52)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(
AbstractController.java:139)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch
(Dispatch
erServlet.java:684)
at
org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:625)
at
org.springframework.web.servlet.FrameworkServlet.processRequest (Frame
workServlet.java:392)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServ
let.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java :709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445
)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1050)
at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter (SetCha
racterEncodingFilter.java :103)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1041)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java :3
54)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:2
26)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java :6
27)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:149)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:123)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
41)
at org.mortbay.jetty.Server.handle(Server.java:269)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:43
0)
at org.mortbay.jetty.HttpConnection$RequestHandler.content
(HttpConnectio
n.java:701)
at org.mortbay.jetty.HttpParser.parseNext (HttpParser.java:617)
at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at
org.mortbay.jetty.nio.HttpChannelEndPoint.run (HttpChannelEndPoint.jav
a:270)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: java.lang.RuntimeException: org.mortbay.jetty.EofException
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:654)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
FeatureReader(FeatureTransformer.java:432)
… 39 more
Caused by: org.mortbay.jetty.EofException
at
org.apache.xml.serializer.ToStream.startElement(ToStream.java:1761)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement (Tra
nsformerIdentityImpl.java:1072)
at
org.geotools.xml.transform.TransformerBase$ContentHandlerFilter.start
Element(TransformerBase.java:372)
at
org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handle
Feature(FeatureTransformer.java:616)
… 40 more

137767 [btpool0-6] INFO org.vfny.geoserver.servlets - Stream abruptly
closed by
client, response aborted
140048 [btpool0-4] INFO org.vfny.geoserver.servlets - Service handled

On 7/26/07, gershwinou <gershwinou@anonymised.com
mailto:[gershwinou@anonymised.com](mailto:gershwinou@anonymised.com)> wrote:

in your startup script ( startup.bat), you should have a line at the
end like (geoserver 1.6beta2):
:runJava
cd %GEOSERVER_HOME%
%RUN_JAVA% -DGEOSERVER_DATA_DIR=“%GEOSERVER_DATA_DIR%”
-Dorg.geotools.referencing.forceXY=true -jar %GEOSERVER_HOME%\start.jar

change it adding -Xmx1024m before -jar:
:runJava
cd %GEOSERVER_HOME%
%RUN_JAVA% -DGEOSERVER_DATA_DIR=“%GEOSERVER_DATA_DIR%”
-Dorg.geotools.referencing.forceXY=true -Xmx1024m -jar
%GEOSERVER_HOME%\start.jar

Cheers

On 26/07/07, Tom (JDi Solutions) < tom.dean@anonymised.com
mailto:[tom.dean@anonymised.com](mailto:tom.dean@anonymised.com)> wrote:

Thanks for your response,

I’m on Windows and there’s plenty of spare physical RAM. With
all running I’ve never seen the system using more than about
1.4GB so there should be 600MB free.

Geoserver does not appear to be spewing loads of messages,
certainly in the command window it remains calm. How do I
increase java heap space exactly?

cheers,

Tom

On 7/26/07, gershwinou < gershwinou@anonymised.com
mailto:[gershwinou@anonymised.com](mailto:gershwinou@anonymised.com)> wrote:

I already used geoserver to serve millions of points from
postgis with no problem…
What can happen is that you eventually overload your RAM and
then geoserver try to deal with the data (well java
actually). Can you check you RAM load (on windows: right
click on the taskbar->task manager; on linux, issue in the
command line “top”) when you retrieve all the data.
Second possibility, sometimes, you hit the maximum java heap
and geoserver can output millions of lines in the logs
(saying you overhead the heap space) and can become mad in
this case… increasing java heap space can help (adding or
changing -Xmx1024m in the java call, look at your startup
script)

Hope it can help

Gersh

On 26/07/07, Tom (JDi Solutions) <
tom.dean@anonymised.com
mailto:[tom.dean@anonymised.com](mailto:tom.dean@anonymised.com) > wrote:

Hi all,

Please see below an email I sent to the uDig list which
it appears may be more relevant to this list. In
summary the issue is as follows:

I’m running uDig 1.1-RC10 Geoserver 1.5.? and Oracle
10.0.2.3 <http://10.0.2.3/> on my laptop (2GB RAM, Intel
core 2 duo CPU) and am testing viewing mastermap for an
entire UK county via WFS. I have 3 layers loaded in
uDig, topographic line, which is all the lines on the
map (there are 4.8 million in the complete table but I’m
only looking at one village in uDig at the moment, the
points which I extracted from topographic line (21
million points in the layer) and a data layer which
compared to the other two is inconsequential.

Initially when the layers are loaded it takes a minute
or so for them to be rendered but once they’re there I
can pan around and zoom with reasonable speed, there’s
usually a second or so delay before a redraw but nothing
prohibitive. The problem is that once uDig has loaded
all the layers the CPU continues to work hard for up to
15 minutes or so after the layers have been loaded, with
no panning or zooming, in fact with no user interaction
at all. Closing uDig does not return the CPU to normal
levels, closing Geoserver immediately does so it looks
like Geoserver and Oracle are the culprits. What’s
going on here?

Tom

!DSPAM:4007,46a86e11276932085621377!

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

!DSPAM:4007,46a86e11276932085621377!

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46a86e11276932085621377!

–
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Andrea_Aime3 · July 26, 2007, 8:32pm

Tom Dean wrote:

Justin, thanks for your thoughts. I'm zoomed in to a specific area of the
map, perhaps less than 1/400th of the total dataset and as I said, the
layer
seems to be rendered correctly and completely but geoserver and oracle
continue to work hard.

Andrea, any thoughts? I could supply the data for you assuming it remains
confidential (it's protected by strict copyright) but obviously it would
be
a large download, the export will prob be a gig for topo_line.

The dataset in "exp" format will help for sure, in "exp" format and
compressed.
It'll help when I come back from my vacation, that is. From here (sea side
with
a 6 old years notebook and a 20kbit/s connection) there is nothing I can
really
do.

The load you see seem to suggest either a large data request, that Geoserver
is trying to satifsy anyways, or a last resort bounding box computation:
when
the datastore is not able to compute the bbox quickly (usually because of
some spatial index or geometry metadata mis-setup) it'll fall down on the
"load all features and extract the bbox from each" approach, which would
be really really costly.

If this is the latter, you can spot easily, go to the feature type config
and
(after properly setting up the SRS) hit "generate bbox", this will compute
the
bbox in lat/lon and also store the native one on disk so that its
computation is
no more needed. When you've done that, apply/save and then try again
hitting Geoserver with uDig.

Good luck
Cheers
Andrea
--
View this message in context: http://www.nabble.com/Overworked-CPU-…-GeoServer—Oracle-tf4150028.html#a11818604
Sent from the GeoServer - User mailing list archive at Nabble.com.

Tom_JDi_Solutions · July 27, 2007, 8:27am

Now there might be something in that… A short while ago I asked whether the bounding box was needed for anything and was told that it’s not so I’ve not been worrying too much about it’s accuracy. When setting up the feature type because there are so many features in the table it takes too long to calculate the max values (don’t know why that should be seeing as there’s a spatial index and you’d think that would make it fast) so I’ve been relying on waiting for the geoserver command prompt window to output the results then convert them using Oracle into lat lng before entering them manually into the bounding box fields. Now, I’m fairly sure they’re correct but the amount of time it takes to calculate them would certainly slow the server down if it’s doing them with every request. So I guess the next question is, under what conditions does it attempt to calculate them? Like I said, despite the slightly strange method of entering them I’m confident they’re right. Also, while geoserver and Oracle continue to whirr away Geoserver outputs references to getLegendGraphic. What does that do and what’s it got to do with a wfs request?

Andrea, if you don’t mind trying this out that would be great. I’ve exported and zipped one of the layers and it comes out at a very respectable 181MB so I can upload that somewhere in a few hours for you to have a go with. For now though, enjoy your holiday!

cheers,

Tom

On 7/26/07, aaime <aaime@anonymised.com> wrote:

Tom Dean wrote:

Justin, thanks for your thoughts. I’m zoomed in to a specific area of the
map, perhaps less than 1/400th of the total dataset and as I said, the
layer
seems to be rendered correctly and completely but geoserver and oracle
continue to work hard.

Andrea, any thoughts? I could supply the data for you assuming it remains
confidential (it’s protected by strict copyright) but obviously it would
be
a large download, the export will prob be a gig for topo_line.

The dataset in “exp” format will help for sure, in “exp” format and
compressed.
It’ll help when I come back from my vacation, that is. From here (sea side
with
a 6 old years notebook and a 20kbit/s connection) there is nothing I can
really
do.

The load you see seem to suggest either a large data request, that Geoserver
is trying to satifsy anyways, or a last resort bounding box computation:
when
the datastore is not able to compute the bbox quickly (usually because of
some spatial index or geometry metadata mis-setup) it’ll fall down on the
“load all features and extract the bbox from each” approach, which would
be really really costly.

If this is the latter, you can spot easily, go to the feature type config
and
(after properly setting up the SRS) hit “generate bbox”, this will compute
the
bbox in lat/lon and also store the native one on disk so that its
computation is
no more needed. When you’ve done that, apply/save and then try again
hitting Geoserver with uDig.

Good luck
Cheers
Andrea

View this message in context: http://www.nabble.com/Overworked-CPU-…-GeoServer—Oracle-tf4150028.html#a11818604
Sent from the GeoServer - User mailing list archive at Nabble.com.

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Geoserver-users mailing list
Geoserver-users@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Andrea_Aime3 · July 27, 2007, 5:50pm

Tom Dean wrote:

Now there might be something in that... A short while ago I asked whether
the bounding box was needed for anything and was told that it's not so
I've
not been worrying too much about it's accuracy.

This is inaccurate. Bbox is used by clients, and we do report the native
bbox too, so if it's not there, it has to be computed. Surprise, the only
way to have it computed is to have Geoserver compute the lat/lon one
(the native gets computed and stored as a side effect).
Please always use "generate bbox" so that both of them are computed.

When setting up the feature
type because there are so many features in the table it takes too long to
calculate the max values (don't know why that should be seeing as there's
a
spatial index and you'd think that would make it fast) so I've been
relying
on waiting for the geoserver command prompt window to output the results
then convert them using Oracle into lat lng before entering them manually
into the bounding box fields. Now, I'm fairly sure they're correct but
the
amount of time it takes to calculate them would certainly slow the server
down if it's doing them with every request. So I guess the next question
is, under what conditions does it attempt to calculate them?

Only if you did not use "generate bbox", that's the only way that I know
(but
I'm unsure about what happens during DescribeFeatureType and don't have
the code available).

Like I said,
despite the slightly strange method of entering them I'm confident they're
right. Also, while geoserver and Oracle continue to whirr away Geoserver
outputs references to getLegendGraphic. What does that do and what's it
got
to do with a wfs request?

uDig does a big lot of requests, not all are strictly necessary. That legend
request is used to show a small icon in the catalog for the layer afaik.

Andrea, if you don't mind trying this out that would be great. I've
exported and zipped one of the layers and it comes out at a very
respectable
181MB so I can upload that somewhere in a few hours for you to have a go
with. For now though, enjoy your holiday!

That would be great. Send me the address and access params by private mail.
Cheers
Andrea
--
View this message in context: http://www.nabble.com/Overworked-CPU-…-GeoServer—Oracle-tf4150028.html#a11833855
Sent from the GeoServer - User mailing list archive at Nabble.com.

Andrea_Aime3 · July 30, 2007, 1:13pm

Tom (JDi Solutions) ha scritto:

Justin, thanks for your thoughts. I'm zoomed in to a specific area of the map, perhaps less than 1/400th of the total dataset and as I said, the layer seems to be rendered correctly and completely but geoserver and oracle continue to work hard.

Andrea, any thoughts? I could supply the data for you assuming it remains confidential (it's protected by strict copyright) but obviously it would be a large download, the export will prob be a gig for topo_line. Alternatively if there's anything relatively simple that I can do from here I'm more than happy to give it a go. You've got my IM details. I'd really appreciate some help with this and I'm sure I won't be the only one to benefit if this issue can be resolved.

Soo, much to my horror and astonishments, I discovered that the Oracle
datastore does not have an optimized bbox computation, and does instead
load each feature to compute the bbox, hence the very long time to
compute the bbox (sigh).

Oracle has two functions for a fast bbox computatin, SDO_TUNE.EXTENT_OF (works only if a spatial index is in place and everything is ok) SDO_AGGR_MBR (slower, does not work in lat/lon, but works also on 3d data).

I've opened an issue about this:
http://jira.codehaus.org/browse/GEOT-1416

Cheers
Andrea

Andrea_Aime3 · July 31, 2007, 9:16am

Tom (JDi Solutions) ha scritto:

Wow. That has had a massive impact. There's still a little bit of work done by Oracle after the map has been rendered but nowhere near what it was before, for nowhere near as long and never consuming more than about 15% of the CPU. On the first attempt it seems to have drawn all the points and lines correctly too (I have emailed about randomly missing ones) but I'll have to run it a good few time before I can be confident on that.

Generating the bbox in the admin console also ran quick enough too.

Very good. If you want the speedup to be even more pronounced, use
generate bbox, submit, apply and save. The native bbox will the stored
permanently along with the lat/lon one and there will be no need to
compute it anymore.

Cheers
Andrea

[Geoserver-users] Overworked CPU .. GeoServer & Oracle

Good luck Cheers Andrea

Good luck
Cheers
Andrea