GeoServer

GeoServer may fail to decode srs codes under high concurrency

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.6.3
  • Fix Version/s: None
  • Component/s: WMS
  • Labels:
    None
  • Number of attachments :
    0

Description

A user reported that under high load with 6 geoservers deployed in the same tomcat some geoserver might stop decoding srs codes, basically rendering wms unusable.

The following exception occurs: 

org.vfny.geoserver.wms.WmsException: Error occurred decoding the espg code EPSG:2393
	at org.geoserver.wms.kvp.GetMapKvpRequestReader.read(GetMapKvpRequestReader.java:164)
	at org.geoserver.ows.Dispatcher.parseRequestKVP(Dispatcher.java:1016)
	at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:385)
	at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:185)
	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.doGet(FrameworkServlet.java:347)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)
Caused by: org.opengis.referencing.FactoryException: Database failure while creating a 'CoordinateReferenceSystem' object for code "EPSG:2393".
	at org.geotools.referencing.factory.epsg.DirectEpsgFactory.databaseFailure(DirectEpsgFactory.java:2848)
	at org.geotools.referencing.factory.epsg.DirectEpsgFactory.createCoordinateReferenceSystem(DirectEpsgFactory.java:1991)
	at org.geotools.referencing.factory.BufferedAuthorityFactory.createCoordinateReferenceSystem(BufferedAuthorityFactory.java:715)
	at org.geotools.referencing.factory.AuthorityFactoryAdapter.createCoordinateReferenceSystem(AuthorityFactoryAdapter.java:744)
	at org.geotools.referencing.factory.BufferedAuthorityFactory.createCoordinateReferenceSystem(BufferedAuthorityFactory.java:715)
	at org.geotools.referencing.factory.AuthorityFactoryAdapter.createCoordinateReferenceSystem(AuthorityFactoryAdapter.java:744)
	at org.geotools.referencing.factory.FallbackAuthorityFactory.createCoordinateReferenceSystem(FallbackAuthorityFactory.java:583)
	at org.geotools.referencing.factory.AuthorityFactoryAdapter.createCoordinateReferenceSystem(AuthorityFactoryAdapter.java:744)
	at org.geotools.referencing.factory.BufferedAuthorityFactory.createCoordinateReferenceSystem(BufferedAuthorityFactory.java:715)
	at org.geotools.referencing.CRS.decode(CRS.java:410)
	at org.geotools.referencing.CRS.decode(CRS.java:338)
	at org.geoserver.wms.kvp.GetMapKvpRequestReader.read(GetMapKvpRequestReader.java:159)
	... 33 more
Caused by: java.sql.SQLException: Connection is closed
	at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
	at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
	at org.hsqldb.jdbc.jdbcConnection.checkClosed(Unknown Source)
	at org.hsqldb.jdbc.jdbcConnection.prepareStatement(Unknown Source)
	at org.geotools.referencing.factory.epsg.DirectEpsgFactory.prepareStatement(DirectEpsgFactory.java:683)
	at org.geotools.referencing.factory.epsg.DirectEpsgFactory.createCoordinateReferenceSystem(DirectEpsgFactory.java:1831)
	... 43 more

Issue Links

This issue depends upon:
GEOT-1770 EPSG HSQL factories cannot recover from connection corruption Major Resolved

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Martin Desruisseaux added a comment -

Maybe it should be reported as a GeoTools bug. This is straight on the "concurrent EPSG factory"' work done last summer. However I don't know if trunk currently uses the old implementation or the new one created by Refractions. I still not yet had the time the review the work and delete the redundancies...

Show
Martin Desruisseaux added a comment - Maybe it should be reported as a GeoTools bug. This is straight on the "concurrent EPSG factory"' work done last summer. However I don't know if trunk currently uses the old implementation or the new one created by Refractions. I still not yet had the time the review the work and delete the redundancies...
Hide
Permalink
Chris Holmes added a comment -

Jody, any insight on this?

Show
Chris Holmes added a comment - Jody, any insight on this?
Hide
Permalink
Jody Garnett added a comment -

Yeah; we need to get Martin to "accept" my changes to the referencing module; this problem is exactly why I did four months of work on referencing last year.

So feedback; switch to trunk (since my changes were rolled out of 2.4.x), and use my alternate EPSG HSQL module (or alternate EPSG Oracle module if you are brave). Realistically it would be good to set up an epsg-h2 module based on my code and stress test it to death, it would:
a) give geoserver one less dependency (ie hsql would not be needed)
b) be isolated from the existing hsql datastore so Martin would not panic and changes

The only problem with my code that is outstanding is a regression when looking up offical CoordinateReferenceSystem objects by using an existing one (generated from WKT).

Show
Jody Garnett added a comment - Yeah; we need to get Martin to "accept" my changes to the referencing module; this problem is exactly why I did four months of work on referencing last year. So feedback; switch to trunk (since my changes were rolled out of 2.4.x), and use my alternate EPSG HSQL module (or alternate EPSG Oracle module if you are brave). Realistically it would be good to set up an epsg-h2 module based on my code and stress test it to death, it would: a) give geoserver one less dependency (ie hsql would not be needed) b) be isolated from the existing hsql datastore so Martin would not panic and changes The only problem with my code that is outstanding is a regression when looking up offical CoordinateReferenceSystem objects by using an existing one (generated from WKT).
Hide
Permalink
Andrea Aime added a comment -

Well, we're goint to switch to trunk the stable series in a couple of months anyways. About using H2, there is a jira issue already, I did adapt the hsql mdoule to h2 months ago: http://jira.codehaus.org/browse/GEOT-1430.
What I'd like to see is an H2 module that uses a zipped database in the classpath, H2 is able to do so: http://www.h2database.com/html/features.html#database_in_zip
There may be performance issues, but that would solve the epsg database ugprade probelms and the temp directory write access issues that have been plaguing geoserver installs for various users (so it's worth a try).

Show
Andrea Aime added a comment - Well, we're goint to switch to trunk the stable series in a couple of months anyways. About using H2, there is a jira issue already, I did adapt the hsql mdoule to h2 months ago: http://jira.codehaus.org/browse/GEOT-1430. What I'd like to see is an H2 module that uses a zipped database in the classpath, H2 is able to do so: http://www.h2database.com/html/features.html#database_in_zip There may be performance issues, but that would solve the epsg database ugprade probelms and the temp directory write access issues that have been plaguing geoserver installs for various users (so it's worth a try).
Hide
Permalink
Jody Garnett added a comment -

Sounds fine; if you want to do that again you will find two authorities in epsg-hsql; mine and martins. Right now only Martin's is advertised via FactorySPI, if you can grab my class over to your GEOT-1430 experiment we can start to proceed without waiting on Martin to review.

Separately I would like to break up the FactorySPI / FactoryRegistry equation; make plug-in responsible for managing / recycling its own instances; and just leave FactorySPI for plug-in discovery.

Show
Jody Garnett added a comment - Sounds fine; if you want to do that again you will find two authorities in epsg-hsql; mine and martins. Right now only Martin's is advertised via FactorySPI, if you can grab my class over to your GEOT-1430 experiment we can start to proceed without waiting on Martin to review. Separately I would like to break up the FactorySPI / FactoryRegistry equation; make plug-in responsible for managing / recycling its own instances; and just leave FactorySPI for plug-in discovery.
Hide
Permalink
Andrea Aime added a comment -

We added better connection checking in the 1.7.x series

Show
Andrea Aime added a comment - We added better connection checking in the 1.7.x series

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.