Hi,
I've just landed on trunk the configuration/catalog locking code we
discussedlast week.
As anticipated it uses a rest callback and a new wicket callback with
readwrite locks to prevent concurrency issues, and it can be disabled
by raisinga system variable.I've added a test that does concurrent
manipulations over different featuretypes via rest, each thread adds a
feature type, checks it's there, reloads the catalog, deletes it
again, with each thread working against a separatefeature type. Before
the locking code it bombed out, now it works fine.
Rest wise the write lock is taken for all attempts to make
modifications(post, delete, put) while a read lock is taken
otherwise,Wicket wise I've made it so that admin reserved pages take a
write lockwhile other pages take a read lock.
The latter allowed me to use the GUI without problems with a
backgroundloop on the shell making rest reload the catalog in a
continuous way(a rest request after the other, that is).
The current test support does not play so well with concurrent
requests,as instantiating a new DispatcherServlet for each test
results in concurrentspring config reloads (not sure why...) so I've
made a small modificationto the test framework that allows selected
tests to build their own dispatcherservlet, and in particular the one
that does concurrent requests buildsone and caches it.I wanted to do
this for all tests but it seems to be breaking some othertests (WPS
ones) in a way I could not understand, so I left it optional.
If anyone wants to have a look the relevant bits are listed here:- the
global locker:
http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/GeoServerConfigurationLock.java-
the rest dispatch callback doing the locks:
http://svn.codehaus.org/geoserver/trunk/src/restconfig/src/main/java/org/geoserver/rest/RestConfigurationLockCallback.java-
the new wicket callback exposing Wicket request life cycle details:
http://svn.codehaus.org/geoserver/trunk/src/web/core/src/main/java/org/geoserver/web/WicketCallback.java-
the implementation doing locks:
http://svn.codehaus.org/geoserver/trunk/src/web/core/src/main/java/org/geoserver/web/WicketConfigurationLockCallback.java
It seems to be all safe changes so I'd like to backport on 2.1.x,but
I'd appreciated if some other core developer could have a look
CheersAndrea
--
-------------------------------------------------------
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
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
-------------------------------------------------------
Looked over the changes, and they look good to me, looks easy enough to disable if need be.
The patch itself though seems riddled with formatting changes…some commented out code was added in GeoServerAbstractTestSupport, etc… it would be nicer if the diff was a bit cleaner, was hard to figure out what was relevant and what was not.
-Justin
On Thu, Nov 17, 2011 at 9:57 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I’ve just landed on trunk the configuration/catalog locking code we
discussedlast week.
As anticipated it uses a rest callback and a new wicket callback with
readwrite locks to prevent concurrency issues, and it can be disabled
by raisinga system variable.I’ve added a test that does concurrent
manipulations over different featuretypes via rest, each thread adds a
feature type, checks it’s there, reloads the catalog, deletes it
again, with each thread working against a separatefeature type. Before
the locking code it bombed out, now it works fine.
Rest wise the write lock is taken for all attempts to make
modifications(post, delete, put) while a read lock is taken
otherwise,Wicket wise I’ve made it so that admin reserved pages take a
write lockwhile other pages take a read lock.
The latter allowed me to use the GUI without problems with a
backgroundloop on the shell making rest reload the catalog in a
continuous way(a rest request after the other, that is).
The current test support does not play so well with concurrent
requests,as instantiating a new DispatcherServlet for each test
results in concurrentspring config reloads (not sure why…) so I’ve
made a small modificationto the test framework that allows selected
tests to build their own dispatcherservlet, and in particular the one
that does concurrent requests buildsone and caches it.I wanted to do
this for all tests but it seems to be breaking some othertests (WPS
ones) in a way I could not understand, so I left it optional.
If anyone wants to have a look the relevant bits are listed here:- the
global locker:
http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/GeoServerConfigurationLock.java-
the rest dispatch callback doing the locks:
http://svn.codehaus.org/geoserver/trunk/src/restconfig/src/main/java/org/geoserver/rest/RestConfigurationLockCallback.java-
the new wicket callback exposing Wicket request life cycle details:
http://svn.codehaus.org/geoserver/trunk/src/web/core/src/main/java/org/geoserver/web/WicketCallback.java-
the implementation doing locks:
http://svn.codehaus.org/geoserver/trunk/src/web/core/src/main/java/org/geoserver/web/WicketConfigurationLockCallback.java
It seems to be all safe changes so I’d like to backport on 2.1.x,but
I’d appreciated if some other core developer could have a look
CheersAndrea
–
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
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
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
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.
On Mon, Nov 21, 2011 at 10:30 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:
Looked over the changes, and they look good to me, looks easy enough to
disable if need be.
The patch itself though seems riddled with formatting changes...some
commented out code was added in GeoServerAbstractTestSupport, etc... it
would be nicer if the diff was a bit cleaner, was hard to figure out what
was relevant and what was not.
Gah, sorry about that, it was not done intentionally, yet that is no excuse,
I should have checked the diff and spotted the problem before committing.
I'll try to backport a clean version of that commit on 2.1.x
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
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
-------------------------------------------------------