The analysis looks pretty good to me but does not provide answers of how to solve this. The first two topics "Cached Content" and "Content Export, Replication to Remote Systems" are the ones where I don't see an option to get rid of the content change triggers. This might not apply to the whole tree, but does this really matter when the tree that needs to be watched contains over 90% of the data?
If I got the problem right the overhead is created by the fact that an event object is created and sent regardles if a consumer cares about it or not. So it might be worth to add something that "asks" the listeners if there is one that would consume this event and (something like an "accepts()" Method handing over raw metadata without generating the event object itself - more like a filter) and send the event then to be consumed by this and potential other consumers. Or did i get something completely wrong? Cheers Dominik On Wed, Oct 23, 2013 at 2:30 PM, Bertrand Delacretaz <bdelacre...@apache.org > wrote: > On Wed, Oct 23, 2013 at 2:10 PM, Carsten Ziegeler <cziege...@apache.org> > wrote: > > ....So far, I heard that the global listener which translates jcr events > into > > OSGi events is a problem - however as far as I followed the discussion, > > this isn't a problem right now but might lead to problems in some time if > > huge Oak based clustered repositories are used... > > Agreed. > > > ...In the same category fall the global listeners we have in the resource > > resolver for the mapping and the i18n one.. > > Is there more?... > > I looked at an analysis the we did earlier this year on our > Sling-based app and I don't have more than that. > > -Bertrand >
