Hi, atm I am investigating in a case, where the JCR observation queue seems to grow and at one point it hits the configured limit, after which observation performance becomes really bad.
I haven't found any JCR observation listener being responsible for it (there are timing data available for them), but I rather think, that the OakResourceListener isn't able to deliver events fast enough (as indicated by JMX). According to my understanding the OakResourceListener transforms JCR observation events into Sling/OSGI resource events; so in my case it seems that these resource events are handled (sometimes?) slow. Is there a chance to see how much time individual event listeners are taking to process an event? And is this processing being done in parallel (using a threadpool) or is this serialized? I need to know which event listener is so slow that this queue starts to fill up. As a workaround we increased the JCR observation size (in Oak as well as in the OakResourceListener), but I would like to know what exactly is causing this behaviour at all. Jörg -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh