onEvent and Session sharing.

[Ian Boston <ie...@tfd.co.uk>]

Hi,

I have been hitting some performance problems with Sling based on Jackrabbit 2.1 and notice a pattern that I think is causing the problem, but want to confirm it with someone more knowledgable. 


The pattern is an javax.jcr.observation.EventListener.onEvent(....) implementation using a session from a containing class provisioned by another thread.

The behaviour is system wide blocking of all threads that provisioned the session in question.

In our case its inside the ACLProviders. We make heavy use of ACLs so every ACLProvider (ie all threads with a session) is intermittently blocked when an ACL modification is made.

Am I reading the situation correctly?
I know that JR 2.2 has made steps forwards in this area, but is there a cure for 2.1 ? 
(like binding casting to EventImpl to avoid a session lookup, as in the SearchManager ?)

There is a similar pattern in
GarbageCollector$Listener
LockManagerImpl
UserAccessControlProvider$CompilePermissions
RetentionRegistryImpl

Although I suspect that none of these are high traffic locations.

Ian

Re: onEvent and Session sharing.

[Ian Boston <ie...@tfd.co.uk>]

On 14 Oct 2010, at 22:01, Ian Boston wrote:

> Hi,
> 
> I have been hitting some performance problems with Sling based on Jackrabbit 2.1 and notice a pattern that I think is causing the problem, but want to confirm it with someone more knowledgable. 
> 
> 
> The pattern is an javax.jcr.observation.EventListener.onEvent(....) implementation using a session from a containing class provisioned by another thread.
> 
> The behaviour is system wide blocking of all threads that provisioned the session in question.
> 
> In our case its inside the ACLProviders. We make heavy use of ACLs so every ACLProvider (ie all threads with a session) is intermittently blocked when an ACL modification is made.
> 
> Am I reading the situation correctly?
> I know that JR 2.2 has made steps forwards in this area, but is there a cure for 2.1 ? 


I did a patch to my version of the standard ACLProvider[1], paths in a queue to be processed by the thread owning the SystemSession (my SystemSessions are bound to thread unlike those in standard JR2.1) and this appears to remove most of the blocking. I havent looked into the other areas yet.


1 http://github.com/sakaiproject/nakamura/commit/d98e78bbdc4b215034e17f85ef52ad1a97d9f9e4#diff-0


> (like binding casting to EventImpl to avoid a session lookup, as in the SearchManager ?)
> 
> There is a similar pattern in
> GarbageCollector$Listener
> LockManagerImpl
> UserAccessControlProvider$CompilePermissions
> RetentionRegistryImpl
> 
> Although I suspect that none of these are high traffic locations.
> 
> Ian
>