Hey Andrea,
thanks a lot for downloading the data and trying it out, I really appreciate
that.
It seems you got it right, now it makes complete sense to me.
aside, I didn't notice a throughput slowdown from 1.5. to 1.6 for GML2 output,
yet we didn't establish a minimum throughput as a requirement, though even if
4M/s seems like not the higher possible rate, I would be glad if it scales
well, say, serving 10 concurrent requests at 4M/s. But that's load testing,
so I hope with the new servers we can at least have a manually ran jmeter
project, as long as we can make the time to work on it, of course.
cheers,
Gabriel
On Thursday 20 December 2007 09:03:18 am Andrea Aime wrote:
Gabriel Roldán ha scritto:
> Thanks Arne, this gives some relief, I'm still hoping it is just
> something wrong on my side.
I can confirm there is something wrong on my side too.
I loaded the gshhs_land data (150MB right?) and asked to generate
the gml2 out of it. The resonse was immediate:
curl
"http://localhost:8080/geoserver/wfs?request=GetFeature&service=WFS&version
=1.0.0&typeName=topp:gshhs_land"
> gshhs_land.gml
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 323M 0 323M 0 0 5379k 0 --:--:-- 0:01:01 --:--:--
8374k
So with WFS 1.0, GML2 output all right, just slow because this
is trunk (on 1.6.0 you can probably get something more like 10MB/s).
The I tried GML3:
C:\Temp\test>curl
"http://localhost:8080/geoserver/wfs?request=GetFeature&service=WFS&version
=1.1.0&typeName=topp:gshhs_land"
> gshhs_land.gml
and the result is:
java.lang.OutOfMemoryError: Java heap space
at
org.geotools.geometry.jts.DefaultCoordinateSequenceTransformer.transform(De
faultCoordinateSequenceTransformer.java:128)
Ah ah, now I get it. The GML3 output defaults on lat/lon axis order, so
we grab the coordinates and reproject them. In this case the coordinate
array is too big to fit the 256MB memory limit I set.
If I remove the transformation imposing a lon/lat output I get an OOM
error too anyways... so indeed the GML3 has higher memory requirements
or memory leaks... not sure were, I mean, with this big geometries it's
enough to keep a few DOM elements representing features around and
kaboom.
I tried with 512 too and 1024mb too, with 1024 in the end it was
able to generate out the xml althought my PC was nearly killed by it
(XP does not like having processes that do consume that much memory,
it enters swap storm).
This is some work for xml-man (aka Justin) to solve I guess. In the
meantime we'll have to tell users to either stay away from huge
geometries, stay away from GML3, or buy lots of memory (pick your
poison) 
Cheers
Andrea
!DSPAM:4045,476a21d6179742092453641!