[Geoserver-devel] Concurrency issues in ResourcePool

Hi,
today I've got reports of errors in ResourcePool due to high load at
the configuration level (up to 50 clients modifying the configuration in
parallel).

The error is the following:

INFO | jvm 1 | 2012/03/16 08:02:28 | java.lang.NullPointerException
STATUS | wrapper | 2012/03/16 08:02:28 | Filter trigger matched.
Firing user_1 event.
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.apache.commons.collections.map.LRUMap.moveToMRU(LRUMap.java:187)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.apache.commons.collections.map.LRUMap.get(LRUMap.java:171)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.ResourcePool.getFeatureType(ResourcePool.java:604)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.ResourcePool.getFeatureType(ResourcePool.java:599)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.impl.FeatureTypeInfoImpl.getFeatureType(FeatureTypeInfoImpl.java:86)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
sun.reflect.GeneratedMethodAccessor388.invoke(Unknown Source)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
java.lang.reflect.Method.invoke(Method.java:597)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:144)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
$Proxy10.getFeatureType(Unknown Source)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.wfs.GetFeature.run(GetFeature.java:383)
INFO | jvm 1 | 2012/03/16 08:02:28 | at

Tracked it down to the unsynchronized access to LRUMap
(http://commons.apache.org/collections/apidocs/org/apache/commons/collections/map/LRUMap.html),
the javadoc is explicit, in case of concurrent access to it a NPE may occurr.

One simple solution is to make the collection synchronized with
Collections.synchronizedMap(...),
which may be a reasonable solution for the very short term (2.1.4 release).

However on trunk we are using a better solution, we use
SoftValueHashMap which is thread
safe and also, when resources allow it, actually does a better job at
caching stuff (in that, it
can contain more than just the minimum hard references).

I was thinking that we could do a backport of the code that's on
trunk, and which has been
working fine for months, once 2.1.4 is out.

What do you think?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

I would be fine either way… i agree backporting the soft value hash map approach seems pretty low risk enough for me for the stable branch. I guess i would vote for that option but no strong opinion.

On Fri, Mar 16, 2012 at 7:17 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
today I’ve got reports of errors in ResourcePool due to high load at
the configuration level (up to 50 clients modifying the configuration in
parallel).

The error is the following:

INFO | jvm 1 | 2012/03/16 08:02:28 | java.lang.NullPointerException
STATUS | wrapper | 2012/03/16 08:02:28 | Filter trigger matched.
Firing user_1 event.
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.apache.commons.collections.map.LRUMap.moveToMRU(LRUMap.java:187)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.apache.commons.collections.map.LRUMap.get(LRUMap.java:171)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.ResourcePool.getFeatureType(ResourcePool.java:604)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.ResourcePool.getFeatureType(ResourcePool.java:599)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.impl.FeatureTypeInfoImpl.getFeatureType(FeatureTypeInfoImpl.java:86)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
sun.reflect.GeneratedMethodAccessor388.invoke(Unknown Source)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
java.lang.reflect.Method.invoke(Method.java:597)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:144)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
$Proxy10.getFeatureType(Unknown Source)
INFO | jvm 1 | 2012/03/16 08:02:28 | at
org.geoserver.wfs.GetFeature.run(GetFeature.java:383)
INFO | jvm 1 | 2012/03/16 08:02:28 | at

Tracked it down to the unsynchronized access to LRUMap
(http://commons.apache.org/collections/apidocs/org/apache/commons/collections/map/LRUMap.html),
the javadoc is explicit, in case of concurrent access to it a NPE may occurr.

One simple solution is to make the collection synchronized with
Collections.synchronizedMap(…),
which may be a reasonable solution for the very short term (2.1.4 release).

However on trunk we are using a better solution, we use
SoftValueHashMap which is thread
safe and also, when resources allow it, actually does a better job at
caching stuff (in that, it
can contain more than just the minimum hard references).

I was thinking that we could do a backport of the code that’s on
trunk, and which has been
working fine for months, once 2.1.4 is out.

What do you think?

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.