jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Mon, 21 Oct 2013 13:57:05 GMT

On Mon, Oct 21, 2013 at 9:47 AM, Bertrand Delacretaz
<bdelacretaz@apache.org> wrote:
> On Mon, Oct 21, 2013 at 3:17 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> ...Instead of an repository problem (like diffing, event creation, etc.),
>> this analysis tells me that the bottleneck here is the application
>> that tries to listen to so many events...
> FWIW, by default Sling does have a listener that catches everything to
> rebroadcast JCR observation events as OSGi events.
> See JcrResourceListener [1] which is created by
> JcrResourceProviderFactory [2] which by default causes it to listen
> for all node/property added/removed/changed events on /.
> That's difficult to modify while staying backwards compatible, as we
> have no way of knowing which events are actually used.
> I don't have a suggestion at this point, just wanted to make sure
> you're aware of this.

Right, it just means that a deployment with such an observer will have
a built-in scalability limit as at some point the listener will no
longer be able to keep up with all concurrent writes across a large
and busy cluster.

For now I'd document this limitation and possibly deprecate the
JcrResourceListener functionality. A deployment can turn the
functionality off once it reaches the scalability limit and has
identified/fixed all affected code.


Jukka Zitting

View raw message