jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject AclProvider$AclPermissions implements SynchronousEventListener
Date Mon, 04 Oct 2010 09:53:06 GMT
Hi
I am seeing deadlocks in our server, which I think is due to the use of a SynchronousEventListener
rather than an Async listener.

Here is what I am seeing.
Thread 1 modifies something including ACL modifications and saves, with Session A
Thread 1 gets a write lock
Thread 1 saves
Thread 1 fires and event that gets dispatched synchronously to the AclProvider$AclPermissions.onEvent()
AclProvider$AclPermissions.onEvent() uses Session B provisioned inside the AclProvider
AclProvider$AclPermissions does a SessionB.getNode(...) which does a LocalStateManager.getGetItemState()
but blocks on a synchronisation on LocalStateManager


meanwhile
Thread 2 using Session B has entered  LocalStateManager.getGetItemState() through the sync
block and is waiting to get a read lock  (pending Thread 1 releasing the write lock) on the
SharedItemStateManager

next
Thread 3,4,5 pile in waiting for read locks in the ShareItemStateManager

Thread 6,7,8 pile in with save operations that started just after Thread 1's save operation
and queue up write lock attempts on the ShareItemStateManager

So:
Other than the obvious fact that the use of the Session object inside the AclProvider needs
to be synchronised (which the underlying session is), what would be the damage caused by converting
to a standard EventListener ?

and would decoupling the write operation from the event dispatch isolate the operations enough
to prevent a deadlock ?


Ian


Mime
View raw message