jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 07:50:47 GMT
Hi,

I think it's quite clear that "global" observation listeners are not
scalable. (Observation listeners that listen for all events below root,
from all cluster nodes.) It is needed for backward compatibility, but we
need to find a solution to make this obsolete. It's not enough to just
reduce the number of such "global" observation listeners: *all* such
observation listeners have to go away. If we don't do that, then we can't
provide a scalable solution. If the customer adds such an global
observation listener, then OK it's his problem. But if our product (Sling,
CQ) requires such an observation listener, then this is our problem and we
need to solve it.

The only option I see is ensuring *each* observation listener only
receives a subset of the events. That filtering could be:

- Only events that were generated from the current cluster node, for
example by implementing a marker interface ("LocalObservationListener").
Jackrabbit 2.x doesn't support such a marker interface yet. Could the
Sling listener (that listens on "/") do this?

- Only events in a specific path (not "/", and probably not "/content" if
this is where most nodes are).

- Only events of a given node type: it would be tricky to make this
scalable within Oak (observation might need to use the node type index).

Are there other ways to filter events?

Regards,
Thomas


Mime
View raw message