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 >
