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 Tue, 22 Oct 2013 13:27:10 GMT

On Tue, Oct 22, 2013 at 5:21 AM, Felix Meschberger <fmeschbe@adobe.com> wrote:
> Am 22.10.2013 um 11:17 schrieb Chetan Mehrotra:
>> I think in Sling case it would make sense for it to be implemented as
>> an Observer. And I had a look at implementation of some of the
>> listener implementations of [1] and I think they can be easily moved
>> to Sling OSGi events
> To be discussed on the Sling list -- though wearing my Sling hat I am
> extremely weary of implementing an Oak-dependency in Sling.
> Sling uses JCR.

Yet Sling is actively looking to expand its support for other non-JCR
backends. ;-)

I think we should do the same thing here, i.e. have an
implementation-independent abstraction in Sling that can be
implemented both by plain JCR and directly by Oak.

As discussed, the main scalability problem with the current
JcrResourceListener design is that it needs to handle *all* changes
and the event producer has no way to know which events really are
needed. To avoid that problem and to make life easier for most typical
listeners, I would suggest adding a whiteboard service interface like
the following:

    interface ContentChangeListener {
        void contentAdded(String pathToAddedNode);
        void contentChanged(String pathToChangedNode);
        void contentRemoved(String pathToRemovedNode);

By registering such a service with a set of filter properties that
identify which content changes are of interest, the client will start
receiving callbacks at these methods whenever such changes are
detected. The filter properties could be something like this:

    paths - the paths under which to listen for changes
    types - the types of nodes of interest
    nodes - the names of nodes of interest
    properties - the names of properties of interest

For example, the following declaration would result in callbacks
whenever there's  a base version change of a versionable README.txt
node somewhere under /source subtree:

    paths = "/source"
    types = "mix:versionable"
    nodes = "README.txt"
    properties = "jcr:baseVersion"

Additionally, a "granularity" property could be set to "coarse" to
indicate that it's fine to deliver events just at the top of a
modified subtree. For example, if changes are detected both at /foo
and /foo/bar, a coarsely grained listener would only need to be
notified at /foo. Setting the property to "fine" would result in
callbacks for both /foo and /foo/bar.

For proper access controls, the service would also need to have a
"credentials" property that contains the access credentials to be used
for determining which events the listener is entitled to.

It should be fairly straightforward to support such a service
interface both with plain JCR observers and with an Oak Observer, with
the latter being potentially orders of magnitude faster.


Jukka Zitting

View raw message