[Geoserver-users] geoserver 1.5.x arcsde pool not closing issue

GeoServer GeoServer User
1

hi All,
I'm new here but I've been struggling with geoserver and geotoosl for a little
while now. I have set up geoserver 1.5.1 with arcsde 9.2 which works fine,
except that arcsde connections are NEVER closed and so I dont get to play for
very long before geoserver has run out of store connections in its pool. I also
get lots of unknown EPSG number errors but the EPSG number was found in the db
and set just fine.
so after some searching I found a reference suggesting that the file: gt2-epsg-
hsql-xx.jar was interfering with correct operation of the EPSG stuff, so I
removed it and tried again - then I get this error (below) which makes me think
that perhaps there is a classpath clash thats causing a silent fault when the
above jar is included since it seems to have an affect on the arcsde
connectionpool.

214526 [INFO] org.vfny.geoserver.servlets.AbstractService - Service handled
?static
java.lang.IllegalAccessException: Class org.vfny.geoserver.global.GeoServer can
not access a member of class org.geotools
.data.arcsde.ConnectionPoolFactory with modifiers "public static synchronized"
        at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
        at java.lang.reflect.Method.invoke(Method.java:578)
        at org.vfny.geoserver.global.GeoServer.destroy(GeoServer.java:703)
        at
org.springframework.beans.factory.support.AbstractBeanFactory$1.destroy
(AbstractBeanFactory.java:916)

has anyone else had these problems? the same problem doesnt exist in geoserver
1.4 but I cant figure out how to set the SRS to 3107 in that version. (i tested
it by adding an arbitrary SRS just to see what would happen - no EPSG not found
errors and no pool problems - I do get date parse probs though+ the srs is
wrong LOL)

Regards
Jason.

2

jeacott@anonymised.com ha scritto:

hi All,
I'm new here but I've been struggling with geoserver and geotoosl for a little while now. I have set up geoserver 1.5.1 with arcsde 9.2 which works fine, except that arcsde connections are NEVER closed and so I dont get to play for very long before geoserver has run out of store connections in its pool.

Glab, it seems there's something in Geoserver that's not closing the connections then? We're in the process of replacing the connection pool
library we do use, but in any case, the current one will keep the connections without releasing them, but in order to run out of connections you nevertheless need more concurrent requests than the limit, or else, you're hitting a bug where connections aren't closed.

I also get lots of unknown EPSG number errors but the EPSG number was found in the db and set just fine.

Saul, Gabriel, how are the CRS coming from ArcSDE built? It seems to me we're having a case of CRS built by hand and having some parameters not matching with the EPSG definiton (eventually, the datum name, which is considered to be an identifier)?

so after some searching I found a reference suggesting that the file: gt2-epsg-
hsql-xx.jar was interfering with correct operation of the EPSG stuff,

If you remove that jar Geoserver will stop working solid as soon as you try to do anything with CRS stuff, since it's the sole source of CRS information for Geoserver.

Cheers
Andrea

3

Thanks for the response,

but in order to run out of
connections you nevertheless need more concurrent requests than the
limit, or else, you're hitting a bug where connections aren't closed.

the connections just arent being released. I get exactly as many request
attempts as there are connections (not concurrent either) before geoserver
starts complaining about no connections available and returning null
transaction errors.

> I also
> get lots of unknown EPSG number errors but the EPSG number was found in the
db
> and set just fine.

Saul, Gabriel, how are the CRS coming from ArcSDE built? It seems to me
we're having a case of CRS built by hand and having some parameters not
matching with the EPSG definiton (eventually, the datum name, which is
considered to be an identifier)?

fyi I'm using an SRS of 3107 and the WFS interface.

Any suggestions on if there may be a simple fix, or how I might work around
this problem would be greatly appreciated.

Thanks
Jason.

4

Jason,

Sorry to hear about the trouble.

I'll be honest, I've never seen anything like this before with the ArcSDE code. Looking at your exception I see something very weird:
...
at org.vfny.geoserver.global.GeoServer.destroy(GeoServer.java:703)
        at
org.springframework.beans.factory.support.AbstractBeanFactory$1.destroy
(AbstractBeanFactory.java:916)
...

That stack trace indicates that this particular message is triggered from the "Geoserver.destroy()" method, which is only called when geoserver is shutting down (I believe!)

I do know that this message appears in the log when geoserver is shut down, as there's a specific class error in the shutdown code, but it shouldn't affect you, and that problem definitely shouldn't cause errors like what you're describing.

Can you increase the logging of the Geoserver a bit, try exactly one 'getfeature' or 'getmap' request and see if anything more interesting comes out of the logs? There are printout statements which indicate that an arcsde connection has been pulled from the pool but never returned, and these should show up if this is happening.

If you continue to get problems like this, I'll send you an 'experimental' build of geoserver off the 1.5.x branch that will help us track this problem down with a better magnifying glass.

--saul

________________________________

From: jeacott@anonymised.com [mailto:jeacott@anonymised.com]
Sent: Tue 6/5/2007 7:40 PM
To: geoserver-users@lists.sourceforge.net
Cc: Andrea Aime; Gabriel Roldán; Saul Farber
Subject: Re: [Geoserver-users] geoserver 1.5.x arcsde pool not closing issue

Thanks for the response,

but in order to run out of
connections you nevertheless need more concurrent requests than the
limit, or else, you're hitting a bug where connections aren't closed.

the connections just arent being released. I get exactly as many request
attempts as there are connections (not concurrent either) before geoserver
starts complaining about no connections available and returning null
transaction errors.

> I also
> get lots of unknown EPSG number errors but the EPSG number was found in the
db
> and set just fine.

Saul, Gabriel, how are the CRS coming from ArcSDE built? It seems to me
we're having a case of CRS built by hand and having some parameters not
matching with the EPSG definiton (eventually, the datum name, which is
considered to be an identifier)?

fyi I'm using an SRS of 3107 and the WFS interface.

Any suggestions on if there may be a simple fix, or how I might work around
this problem would be greatly appreciated.

Thanks
Jason.

5

ok this time I notice this startup problem:

49082 [FINER] org.geotools.data.arcsde.ArcSDEDataStoreFactory -
com.esri.sde.sdk.client.SeConnection is in place.
49272 [FINER] org.geotools.data.arcsde.ArcSDEDataStoreFactory -
com.esri.sde.sdk.pe.PeCoordinateSystem is in place.
49286 [FINE] org.geotools.data.property.PropertyDataStoreFactory - can't
process parameters
java.io.IOException: Parameter directory is required:Directory containting
property files
  at org.geotools.data.DataStoreFactorySpi$Param.lookUp
(DataStoreFactorySpi.java:396)
  at org.geotools.data.property.PropertyDataStoreFactory.directoryLookup
(PropertyDataStoreFactory.java:185)
  at org.geotools.data.property.PropertyDataStoreFactory.canProcess
(PropertyDataStoreFactory.java:154)
  at org.geotools.data.DataStoreFinder.getDataStore
(DataStoreFinder.java:94)
  at org.vfny.geoserver.global.DataStoreInfo.getDataStore
(DataStoreInfo.java:208)
  at org.vfny.geoserver.global.Data.loadFeatureTypes(Data.java:536)
  at org.vfny.geoserver.global.Data.load(Data.java:235)

Any clues as to what directory it thinks its missing?

Quoting "Farber, Saul \\(EEA\\)" <Saul.Farber@anonymised.com>:

Jason,

Sorry to hear about the trouble.

I'll be honest, I've never seen anything like this before with the ArcSDE
code. Looking at your exception I see something very weird:
...
at org.vfny.geoserver.global.GeoServer.destroy(GeoServer.java:703)
        at
org.springframework.beans.factory.support.AbstractBeanFactory$1.destroy
(AbstractBeanFactory.java:916)
...

That stack trace indicates that this particular message is triggered from the
"Geoserver.destroy()" method, which is only called when geoserver is shutting
down (I believe!)

I do know that this message appears in the log when geoserver is shut down,
as there's a specific class error in the shutdown code, but it shouldn't
affect you, and that problem definitely shouldn't cause errors like what
you're describing.

Can you increase the logging of the Geoserver a bit, try exactly one
'getfeature' or 'getmap' request and see if anything more interesting comes
out of the logs? There are printout statements which indicate that an arcsde
connection has been pulled from the pool but never returned, and these should
show up if this is happening.

If you continue to get problems like this, I'll send you an 'experimental'
build of geoserver off the 1.5.x branch that will help us track this problem
down with a better magnifying glass.

--saul

________________________________

From: jeacott@anonymised.com [mailto:jeacott@anonymised.com]
Sent: Tue 6/5/2007 7:40 PM
To: geoserver-users@lists.sourceforge.net
Cc: Andrea Aime; Gabriel Roldán; Saul Farber
Subject: Re: [Geoserver-users] geoserver 1.5.x arcsde pool not closing issue

Thanks for the response,

> but in order to run out of
> connections you nevertheless need more concurrent requests than the
> limit, or else, you're hitting a bug where connections aren't closed.

the connections just arent being released. I get exactly as many request
attempts as there are connections (not concurrent either) before geoserver
starts complaining about no connections available and returning null
transaction errors.

> > I also
> > get lots of unknown EPSG number errors but the EPSG number was found in
the
> db
> > and set just fine.
>
> Saul, Gabriel, how are the CRS coming from ArcSDE built? It seems to me
> we're having a case of CRS built by hand and having some parameters not
> matching with the EPSG definiton (eventually, the datum name, which is
> considered to be an identifier)?

fyi I'm using an SRS of 3107 and the WFS interface.

Any suggestions on if there may be a simple fix, or how I might work around
this problem would be greatly appreciated.

Thanks
Jason.

6

jeacott@anonymised.com ha scritto:

ok this time I notice this startup problem:

49082 [FINER] org.geotools.data.arcsde.ArcSDEDataStoreFactory - com.esri.sde.sdk.client.SeConnection is in place.
49272 [FINER] org.geotools.data.arcsde.ArcSDEDataStoreFactory - com.esri.sde.sdk.pe.PeCoordinateSystem is in place.
49286 [FINE] org.geotools.data.property.PropertyDataStoreFactory - can't process parameters
java.io.IOException: Parameter directory is required:Directory containting property files
  at org.geotools.data.DataStoreFactorySpi$Param.lookUp
(DataStoreFactorySpi.java:396)
  at org.geotools.data.property.PropertyDataStoreFactory.directoryLookup
(PropertyDataStoreFactory.java:185)
  at org.geotools.data.property.PropertyDataStoreFactory.canProcess
(PropertyDataStoreFactory.java:154)
  at org.geotools.data.DataStoreFinder.getDataStore
(DataStoreFinder.java:94)
  at org.vfny.geoserver.global.DataStoreInfo.getDataStore
(DataStoreInfo.java:208)
  at org.vfny.geoserver.global.Data.loadFeatureTypes(Data.java:536)
  at org.vfny.geoserver.global.Data.load(Data.java:235)

Any clues as to what directory it thinks its missing?

This message comes from the property data store, which is used for tests, I don't know why is misconfigured in your case, but it's not
relevant to your issues.

It would be nice if you could wipe out the logs, start a fresh Geoserver
instance, raise the logging level to FINE in the geoserver/server configuration section, hit it with requests until the issues shows up, create a jira issue, and attach the full log there (compressed, since
it'll be big I think).
Cheers
Andrea

7

ok - I've been experimenting with geoserver and I know how to reliably break it.
I installed a fresh geoserver 1.5.1 and have logs if anyone is interested I can
send
them.
geoserver only falls over when I'm accessing featuretypes I've configured under
arcsde, but not any of the built in data geoserver.
when I create a new arcsde sourced featuretype, geoserver correctly finds the
information for 3107 when each featuretype is configured, but reports unknown
EPSG_NUMBER when I run a query. I have 2 connections configured and I get to
run this query exactly once before catastrophic failure.
The values in the returned Envelope are also strange (to me anyway) - eg: Env
[1330545.498 : 1330545.498, 2128322.41200006 : 2128322.41200006]

during geoserver startup there are LOTS of these errors:
10003 [FINER] org.geotools.data.arcsde.ArcSDEDataStoreFactory -
com.esri.sde.sdk.client.SeConnection is in place.
10169 [FINER] org.geotools.data.arcsde.ArcSDEDataStoreFactory -
com.esri.sde.sdk.pe.PeCoordinateSystem is in place.
10171 [FINE] org.geotools.data.property.PropertyDataStoreFactory - can't
process parameters
java.io.IOException: Parameter directory is required:Directory containting
property files
  at org.geotools.data.DataStoreFactorySpi$Param.lookUp
(DataStoreFactorySpi.java:396) ...

response from first query:
7/06/2007 11:36:25 org.geotools.data.wfs.WFSDataStore getSchema
WARNING: Unknown EPSG_NUMBER
7/06/2007 11:36:25 org.geotools.data.wfs.NonStrictWFSStrategy clipBBox
WARNING: Unknown EPSG_NUMBER
2007-06-07 11:36:31,134 [main] DEBUG org.geotools.demo.example.WFSJTest -
Feature[ id=TOPO.GAZETTEER.18 , OBJECTID=null , RECNO=SA0041191 ,
DATE_CR_AL=Wed Mar 08 00:00:00 CST 1995 , NAME=Long Horse Paddock ,
F_CODE=PDK , OTHERDETLS= , SOURCE= , CLASS=LOCL , U_M=U , GDA94_LAT=-30.79205 ,
GDA94_LONG=138.46177 , PUBLIC_REL=Y , SHAPE=POINT (1330545.498
2128322.41200006) ]
2007-06-07 11:36:31,150 [main] DEBUG org.geotools.demo.example.WFSJTest -
pixeltest null
2007-06-07 11:36:31,150 [main] DEBUG org.geotools.demo.example.WFSJTest -
pixeltest Env[1330545.498 : 1330545.498, 2128322.41200006 : 2128322.41200006]

response from second attempt at same query:
7/06/2007 11:40:26 org.geotools.data.wfs.WFSDataStore getSchema
WARNING: Unknown EPSG_NUMBER
7/06/2007 11:40:26 org.geotools.data.wfs.NonStrictWFSStrategy clipBBox
WARNING: Unknown EPSG_NUMBER
7/06/2007 11:40:30 org.geotools.xml.XMLSAXHandler processException
SEVERE: 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
(GML2FeatureResponseDelegate.java:212)
  at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo
(FeatureResponse.java:127)
  at org.vfny.geoserver.servlets.AbstractService.doService
(AbstractService.java:582)
  at org.vfny.geoserver.servlets.AbstractService.doPost
(AbstractService.java: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.java:52)
  at org.springframework.web.servlet.mvc.AbstractController.handleRequest
(AbstractController.java:139)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle
(SimpleControllerHandlerAdapter.java:44)
  at org.springframework.web.servlet.DispatcherServlet.doDispatch
(DispatcherServlet.java:684)
  at org.springframework.web.servlet.DispatcherServlet.doService
(DispatcherServlet.java:625)
  at org.springframework.web.servlet.FrameworkServlet.processRequest
(FrameworkServlet.java:392)
  at org.springframework.web.servlet.FrameworkServlet.doPost
(FrameworkServlet.java:357)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
  at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter
(SetCharacterEncodingFilter.java:103)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:202)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
  at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:213)
  at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:178)
  at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
  at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:105)
  at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
  at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
  at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:869)
  at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConne
ction(Http11BaseProtocol.java:664)
  at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
(PoolTcpEndpoint.java:527)
  at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
(LeaderFollowerWorkerThread.java:80)
  at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:684)
  at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: error reading FeatureResults
  at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:423)
  at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse
(TransformerBase.java:625)
  at org.apache.xalan.transformer.TransformerIdentityImpl.transform
(TransformerIdentityImpl.java:484)
  at org.geotools.xml.transform.TransformerBase$Task.run
(TransformerBase.java:293)
  at org.geotools.xml.transform.TransformerBase.transform
(TransformerBase.java:126)
  ... 33 more
Caused by: org.geotools.data.DataSourceException: The maximun of 2 to
org.geotools.data.arcsde.ConnectionConfig[dbtype=arcsde, server=leela,
port=5152, instance=null, user=---, password=---, minConnections=2,
maxConnections=2, connTimeOut=1000] has been reached
  at org.geotools.data.arcsde.ArcSDEConnectionPool.getSdeLayer
(ArcSDEConnectionPool.java:297)
  at org.geotools.data.arcsde.ArcSDEQuery.createFilters
(ArcSDEQuery.java:278)
  at org.geotools.data.arcsde.ArcSDEQuery.createQuery
(ArcSDEQuery.java:194)
  at org.geotools.data.arcsde.ArcSDEDataStore.getFeatureReader
(ArcSDEDataStore.java:538)
  at org.geotools.data.arcsde.ArcSDEDataStore.getFeatureReader
(ArcSDEDataStore.java:592)
  at org.geotools.data.DefaultFeatureResults.reader
(DefaultFeatureResults.java:150)
  at org.geotools.data.crs.ReprojectFeatureResults.reader
(ReprojectFeatureResults.java:155)
  at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
  ... 37 more
Caused by: org.geotools.data.arcsde.UnavailableConnectionException: The maximun
of 2 to org.geotools.data.arcsde.ConnectionConfig[dbtype=arcsde, server=leela,
port=5152, instance=null, user=---, password=---, minConnections=2,
maxConnections=2, connTimeOut=1000] has been reached
  at org.geotools.data.arcsde.ArcSDEConnectionPool.getConnection
(ArcSDEConnectionPool.java:239)
  at org.geotools.data.arcsde.ArcSDEConnectionPool.getSdeLayer
(ArcSDEConnectionPool.java:295)
  ... 44 more

server log:
540104 [FINE] org.vfny.geoserver.global.Data - getting type sde:TOPO.GAZETTEER
540108 [FINE] org.vfny.geoserver.wfs.responses.FeatureResponse - Query is
  Query
   feature type: sde:TOPO.GAZETTEER
   [properties: ALL ]
To gt2: Query:
   feature type: TOPO.GAZETTEER
   filter: Filter.NONE
   [properties: ALL ]
540132 [FINER] org.vfny.geoserver.servlets.AbstractService - execution succeed
540133 [FINEST] org.vfny.geoserver.servlets.AbstractService - getting strategy
output
540162 [FINER] org.vfny.geoserver.servlets.AbstractService - strategy output
is: java.io.BufferedOutputStream
540163 [FINE] org.vfny.geoserver.servlets.AbstractService - mime type is:
text/xml; charset=UTF-8
540163 [FINE] org.vfny.geoserver.servlets.AbstractService - content encoding
is: null
540165 [FINE] org.geotools.data.arcsde.ArcSDEQuery - Creating new ArcSDEQuery
540166 [FINEST]
org.geotools.data.arcsde.ArcSDEConnectionPool$SeConnectionFactory - activating
connection org.geotools.data.arcsde.PooledConnection@anonymised.com
540173 [FINER] AbstractFilter - ENTRY 12,345
540174 [FINE] org.geotools.data.arcsde.ArcSDEQuery$FilterSet - SQL portion of
SDE Query: 'Filter.NONE'
540174 [FINEST]
org.geotools.data.arcsde.ArcSDEConnectionPool$SeConnectionFactory - activating
connection org.geotools.data.arcsde.PooledConnection@anonymised.com
540175 [FINE] org.geotools.data.arcsde.ArcSDEQuery - constructing new sql query
with connection: org.geotools.data.arcsde.PooledConnection@anonymised.com, propnames:
[OBJECTID, RECNO, DATE_CR_AL, NAME, F_CODE, OTHERDETLS, SOURCE, CLASS, U_M,
GDA94_LAT, GDA94_LONG, PUBLIC_REL, SHAPE] sqlConstruct where clause: 'null
542351 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 18
from column OBJECTID
542353 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 19
from column OBJECTID
542354 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 29
from column OBJECTID
542355 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 30
from column OBJECTID
542357 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 44
from column OBJECTID
542358 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 45
from column OBJECTID
542359 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 46
from column OBJECTID
542360 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 47
from column OBJECTID
542362 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 57
from column OBJECTID
542363 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 58
from column OBJECTID
542364 [FINE] org.geotools.data.arcsde.ArcSDEAttributeReader - Fetched fid 82
from column OBJECTID
542366 [FINE] org.geotools.data.arcsde.ArcSDEQuery - Creating new ArcSDEQuery
543372 [WARNING] org.geotools.data.arcsde.ArcSDEConnectionPool - Getting
connection: Timeout waiting for idle object
java.util.NoSuchElementException: Timeout waiting for idle object
  at org.apache.commons.pool.impl.GenericObjectPool.borrowObject
(GenericObjectPool.java:825)
  at org.geotools.data.arcsde.ArcSDEConnectionPool.getConnection
(ArcSDEConnectionPool.java:236)
  at org.geotools.data.arcsde.ArcSDEConnectionPool.getSdeLayer
(ArcSDEConnectionPool.java:295)
  at org.geotools.data.arcsde.ArcSDEQuery.createFilters
(ArcSDEQuery.java:278)
  at org.geotools.data.arcsde.ArcSDEQuery.createQuery
(ArcSDEQuery.java:194)
  at org.geotools.data.arcsde.ArcSDEDataStore.getFeatureReader
(ArcSDEDataStore.java:538)
  at org.geotools.data.arcsde.ArcSDEDataStore.getFeatureReader
(ArcSDEDataStore.java:592)
  at org.geotools.data.DefaultFeatureResults.reader
(DefaultFeatureResults.java:150)
  at org.geotools.data.crs.ReprojectFeatureResults.reader
(ReprojectFeatureResults.java:155)
  at org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.encode
(FeatureTransformer.java:414)
  at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse
(TransformerBase.java:625)
  at org.apache.xalan.transformer.TransformerIdentityImpl.transform
(TransformerIdentityImpl.java:484)
  at org.geotools.xml.transform.TransformerBase$Task.run
(TransformerBase.java: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
(GML2FeatureResponseDelegate.java:212)
  at org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo
(FeatureResponse.java:127)
  at org.vfny.geoserver.servlets.AbstractService.doService
(AbstractService.java:582)
  at org.vfny.geoserver.servlets.AbstractService.doPost
(AbstractService.java: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.java:52)
  at org.springframework.web.servlet.mvc.AbstractController.handleRequest
(AbstractController.java:139)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle
(SimpleControllerHandlerAdapter.java:44)
  at org.springframework.web.servlet.DispatcherServlet.doDispatch
(DispatcherServlet.java:684)
  at org.springframework.web.servlet.DispatcherServlet.doService
(DispatcherServlet.java:625)
  at org.springframework.web.servlet.FrameworkServlet.processRequest
(FrameworkServlet.java:392)
  at org.springframework.web.servlet.FrameworkServlet.doPost
(FrameworkServlet.java:357)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
  at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter
(SetCharacterEncodingFilter.java:103)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:202)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
  at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:213)
  at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:178)
  at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
  at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:105)
  at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
  at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
  at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:869)
  at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConne
ction(Http11BaseProtocol.java:664)
  at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
(PoolTcpEndpoint.java:527)
  at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
(LeaderFollowerWorkerThread.java:80)
  at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:684)
  at java.lang.Thread.run(Thread.java:595)
org.geotools.data.DataSourceException: The maximun of 2 to
org.geotools.data.arcsde.ConnectionConfig[dbtype=arcsde, server=leela,
port=5152, instance=null, user=---, password=---, minConnections=2,
maxConnections=2, connTimeOut=1000] has been reached
  at org.geotools.data.arcsde.ArcSDEConnectionPool.getSdeLayer
(ArcSDEConnectionPool.java:297)
  at org.geotools.data.arcsde.ArcSDEQuery.createFilters
(ArcSDEQuery.java:278)
  at org.geotools.data.arcsde.ArcSDEQuery.createQuery
(ArcSDEQuery.java:194)
  at org.geotools.data.arcsde.ArcSDEDataStore.getFeatureReader
(ArcSDEDataStore.java:538)

any thoughts greatly appreciated.
Thanks
Jason.

8

Gabriel Roldán ha scritto:

Hi guys,

I'm looking at this issue, gonna fix it asap (guess today).

Question:
SDE gets the CRS of a given feature type by parsing its WKT. Unfortunately, the WKT ArcSDE returns is not complete (as in not containing the authority metadata and the like). Nonentheless, it its true that it'd be great, if not a blocking mandate, to be able to correctly expose the EPSG CRS. I'm not too confident that using CRS.equalsIgnoreMetadata() will pay off, as if I have to traverse the 6000+ CRS's in the EPSG database to find out which one is equivalent to the one returned by ArcSDE, it's gonna be a huge performance penalty and I guess there are no guarantees that I'll find it anyway. But I didn't tried that yet, to be honest.

So Andrea, do you think it might work? guess you already worked on similar a problem.

Well, trying to match EPSG CRS with a WKT definiton is what the LOOKUP CRS button does in the featuretype config panel, and you're both right
in saying it's expensive, and not guaranteed to find an EPSG code.
This is not necessary, either.
In Geosersver, the user wil have to do this manually just once.

If future versions of Geoserver I'll make sure the user can have a choice of how to handle this issue, but I've not yet made up my mind on
details yet.
The current policy, described at http://docs.codehaus.org/display/GEOSDOC/Configuring+your+data+Coordinate+Reference+System
is proving to be inadequate, and I've already opened a jira issue to
try and improve this: http://jira.codehaus.org/browse/GEOS-1126.

If you have thought on how to handle the differences between the CRS
declared in the data store and the one declared by the user, I'm all ears.

Cheers
Andrea

9

On Thursday 07 June 2007 11:09:49 Andrea Aime wrote:

Gabriel Roldán ha scritto:
> Hi guys,
>
> I'm looking at this issue, gonna fix it asap (guess today).
>
> Question:
> SDE gets the CRS of a given feature type by parsing its WKT.
> Unfortunately, the WKT ArcSDE returns is not complete (as in not
> containing the authority metadata and the like). Nonentheless, it its
> true that it'd be great, if not a blocking mandate, to be able to
> correctly expose the EPSG CRS. I'm not too confident that using
> CRS.equalsIgnoreMetadata() will pay off, as if I have to traverse the
> 6000+ CRS's in the EPSG database to find out which one is equivalent to
> the one returned by ArcSDE, it's gonna be a huge performance penalty and
> I guess there are no guarantees that I'll find it anyway. But I didn't
> tried that yet, to be honest.
>
> So Andrea, do you think it might work? guess you already worked on
> similar a problem.

Well, trying to match EPSG CRS with a WKT definiton is what the LOOKUP
CRS button does in the featuretype config panel, and you're both right
in saying it's expensive, and not guaranteed to find an EPSG code.
This is not necessary, either.
In Geosersver, the user wil have to do this manually just once.

If future versions of Geoserver I'll make sure the user can have a
choice of how to handle this issue, but I've not yet made up my mind on
details yet.
The current policy, described at
http://docs.codehaus.org/display/GEOSDOC/Configuring+your+data+Coordinate+R
eference+System is proving to be inadequate, and I've already opened a jira
issue to try and improve this: http://jira.codehaus.org/browse/GEOS-1126.

If you have thought on how to handle the differences between the CRS
declared in the data store and the one declared by the user, I'm all ears.

Cheers
Andrea

You're right that would fix it for GeoServer. The problem still bothers me
because there are no way of forcing the correct CRS outside of geoserver.
Well, in uDig you could do something similar, still I would like to easy the
life of users and get the plugin reporting the correct CRS, but agreed its a
tough problem..

Gabriel

10

Thanks all, I really appreciate the effort and prompt response to my issue.
hopefully someone will find a solution. There must be something fundamentally
wrong somewhere though since I would have thought connections should always be
closed/returned to the pool regardless or circumstance.

Good Luck.
Jason.

Quoting Gabriel Roldán <groldan@anonymised.com>:

On Thursday 07 June 2007 11:09:49 Andrea Aime wrote:
> Gabriel Roldán ha scritto:
> > Hi guys,
> >
> > I'm looking at this issue, gonna fix it asap (guess today).
> >
> > Question:
> > SDE gets the CRS of a given feature type by parsing its WKT.
> > Unfortunately, the WKT ArcSDE returns is not complete (as in not
> > containing the authority metadata and the like). Nonentheless, it its
> > true that it'd be great, if not a blocking mandate, to be able to
> > correctly expose the EPSG CRS. I'm not too confident that using
> > CRS.equalsIgnoreMetadata() will pay off, as if I have to traverse the
> > 6000+ CRS's in the EPSG database to find out which one is equivalent to
> > the one returned by ArcSDE, it's gonna be a huge performance penalty and
> > I guess there are no guarantees that I'll find it anyway. But I didn't
> > tried that yet, to be honest.
> >
> > So Andrea, do you think it might work? guess you already worked on
> > similar a problem.
>
> Well, trying to match EPSG CRS with a WKT definiton is what the LOOKUP
> CRS button does in the featuretype config panel, and you're both right
> in saying it's expensive, and not guaranteed to find an EPSG code.
> This is not necessary, either.
> In Geosersver, the user wil have to do this manually just once.
>
> If future versions of Geoserver I'll make sure the user can have a
> choice of how to handle this issue, but I've not yet made up my mind on
> details yet.
> The current policy, described at
>
http://docs.codehaus.org/display/GEOSDOC/Configuring+your+data+Coordinate+R
>eference+System is proving to be inadequate, and I've already opened a jira
> issue to try and improve this: http://jira.codehaus.org/browse/GEOS-1126.
>
> If you have thought on how to handle the differences between the CRS
> declared in the data store and the one declared by the user, I'm all ears.
>
> Cheers
> Andrea

You're right that would fix it for GeoServer. The problem still bothers me
because there are no way of forcing the correct CRS outside of geoserver.
Well, in uDig you could do something similar, still I would like to easy the

life of users and get the plugin reporting the correct CRS, but agreed its a

tough problem..

Gabriel