ConcurrentModificationException in GetFeature under heavy load
--------------------------------------------------------------
Key: GEOS-4329
URL: http://jira.codehaus.org/browse/GEOS-4329
Project: GeoServer
Issue Type: Bug
Affects Versions: 2.1-RC1
Reporter: Andrea Aime
Assignee: Justin Deoliveira
Fix For: 2.1-RC2
Under heavy load of both GetFeature and DescribeFeatureType we get failures in GetFeature in roughly 10% of the GetFeature requests with the following stack trace:
{code}
2011-01-26 08:50:22,030 ERROR [geoserver.ows] -
java.util.ConcurrentModificationException
at org.eclipse.emf.common.util.BasicEList$EIterator.checkModCount(BasicEList.java:1327)
at org.eclipse.emf.common.util.BasicEList$EIterator.next(BasicEList.java:1275)
at org.geotools.xml.Encoder.encode(Encoder.java:726)
at org.geotools.xml.Encoder.encode(Encoder.java:563)
at org.geoserver.wfs.xml.GML3OutputFormat.encode(GML3OutputFormat.java:253)
at org.geoserver.wfs.xml.GML3OutputFormat.write(GML3OutputFormat.java:241)
at org.geoserver.wfs.WFSGetFeatureOutputFormat.write(WFSGetFeatureOutputFormat.java:141)
at org.geoserver.ows.Dispatcher.response(Dispatcher.java:751)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:233)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
{code}
This is probably related to the substitution group handling in gt-xsd as the problem occurrs while visiting substitution groups for _Feature.
The patches committed on GeoTools at revision 35934,35936,35937 have been beneficial in this respect, as the same test against GS 2.0.2
results in well over 90% failures instead (which do start with the same stack trace, but eventually lead to NPE as some null finds its way into
the substitution group list), but I guess it's not enough since it's still possible to reproduce failures.
I'm going to attach a JMeter script that makes the problem evident: it creates two groups of 40 threads that do run concurrently, one makes
a lot of DFT (8000, as they are quick to process), the other one some GetFeature (800).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira