Hi Gabriel,
now i made i new test. I tested an ArcSDE instance with less FeatureTypes (approx. 70) and the same version (9.2) like the jsde and jpe jars i use. I still wasn’t able to create the datastore, but now i have some different behaviour of geoserver than before.
First: When i was looking into the ArcSDE log file, the signal from geoserver was arriving at ArcSDE instance. But then ArcSDE had no further actions from the client (geoserver) and quit with the error code ‘8’ which means: ‘lost the client’.
Second: I din’t get the error ‘java heap space’ anymore (which confirms my assumption that this error message doesn’t reflect the real reason of the exception).
Third: Instead of the former message i get a NullPointerException (Unable to fetch a list of FeatureType names from datastore).
Fourth: geoserver throws an exception when initializing af restart:
24 Apr 08:48:08 DEBUG [geotools.arcsde] - com.esri.sde.sdk.client.SeConnection is in place.
24 Apr 08:48:08 DEBUG [geotools.arcsde] - com.esri.sde.sdk.pe.PeCoordinateSystem is in place.
24 Apr 08:48:08 DEBUG [data.property] - can’t process parameters
java.io.IOException: Parameter directory is required:Directory containting property files
But this is really strange, because this is during initialisation and should have been coming in the former tests too, because this error has nothing to do with my trial to connect to the datastore and i haven’t changed any configurations or binaries since my last posting :o/
Anyway, maybe this brings us a step forward?..
I attached the log file if you need to view the whole.
Cheers
Albrecht
Hi Albrecht,
First off, you’re right this seems like there should be
enough memory to
retrieve 300+ layers. I object to assume 300 SeLayer
instances can eat 1G of
heap space!In that getAvailableLayerNames() method we have to call
SeConnection.getLayers():Vector, which returns a
vector with all
your layers.Now, I wonder if we’re looking at the correct spot and if so,
if it might be
some sort of version hell, and if not, where are we messing up…Lets start with a couple questions, since I guess noone of us
is able to test
over a 8.3 instance:
- what ArcSDE Java API version are you using (jsde_sdk, et
all)? If using 9.0,
9.1 or 9.2, did you try with the 8.3 jars that match your sde
version? (I’m
not sure they would work though)- did you try connecting to another instance with less layers
to see if its
actually a problem with the layer count?- could you let me connect to your test server somehow?
Cheers,
Gabriel
On Tuesday 22 April 2008 11:35:37 am
Albrecht.Weiser@anonymised.com wrote:Hi Saul, Hi Gabriel,
i’m afraid you’re right, Saul, i’m trying to connect to an
ArcSDE instance
which manages up to 324 different FeatureTypes (layers). Most of the
FeatureTypes are specialiced geodata and don’t contain more
than some
thousand datasets. But some are geo-basic data like
cadastral data of the
federal country hessen with XX millions of datasets. The
system i want to
connect to is a governmental productive data server system. I’m just
testing the possibilities of geoserver to work with an
ArcSDE backend and
therefore im doing it on my office pc with 1024 BM RAM. I
agree with you if
you say that’s not very much power, but even though its a
high amount of
FeatureTypes to gather, the memory should be enough
shouldn’t it? O.K. i
set the java heap space up to 768 MB which is the highest
level my pc could
afford. I’m working on a windows XP platform (because later
geoserver
should also run on a windows 2003 server platform). There i
don’t need to
set the heap space in the start script - i can do it in the
Apache Tomcat
properties window. Therefore i don’t have problems with wrong script
settings of -Xms -Xmx. I monitored the task manager when
starting tomcat:
the memory was rising up to 1200MB (with a swapfile of 1.2
GB). Therefore i
think that the JVM is getting the proper amount of memory.
But i’m still
wondering that an ArcSDE datastore should need so much
memory. Formerly i
built a datastore with a direct connection to the oracle db
where ArcSDE
sits upon. That worked properly even though there were the
same amount of
FeatureTypes than in my test with the ArcSDE datastore. For
me that means,
that there must be in principle enough memory for the
connection!? I’m
working with geoserver 1.6.3 (where can i explore the full
release-number?
Geoserver doesn’t log it unfortunately). The ArcSDE is 8.3
and it connects
to an oracle 9i dbms.
best wishes
Albrecht-----Ursprüngliche Nachricht-----
Von: Saul Farber [mailto:sjf8@anonymised.com]
Gesendet: Montag, 21. April 2008 17:15
An: Gabriel Roldán
Cc: geoserver-users@anonymised.com.sourceforge.net; Weiser, Albrecht (HZD)
Betreff: Re: [Geoserver-users] ArcSDE Backend:Please help,
i’m stuck;
Stilldin’t get an ArcSDE connectionGabriel,
I’d say that this looks like a really large number of
layers is eating
all the memory. Check lower in the stack trace:…
org.geotools.arcsde.pool.ArcSDEConnectionPool.getAvailableLay
erNames(ArcSDEConnectionPool.java:413) …
Albrecht:
I’d say you should increase the JVM heap size on your computer even
higher, and double-check that your heap size setting is getting
propagated through to your running code. Is it possible
there’s a typo
or some disconnect that’s not giving your JVM the proper amount of
memory?–saul
!DSPAM:4045,480db18297681030819293!