jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 13:41:02 GMT
Hi

Am 22.10.2013 um 15:27 schrieb Jukka Zitting:

> Hi,
> 
> 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. ;-)


That bears an interesting question, though: What is the relationship of Oak to JCR ?

> 
> 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:

What you are describing is already implemented in the JcrResourceListener and the OSGi EventAdmin
service ;-)

The JcrResourceListener just gets JCR Observation events, creates the OSGi Event objects and
hands them over for distribution by the OSGi EventAdmin service. The latter service is then
responsible for dispatching taking the EventHandler service registration properties into account
for filtering.

Events are collated on a node level with names of added, removed, and modified properties
listed in event properties and the node path provided by the path property. Plus we add an
indication of whether the event occurred locally or on another cluster node as well as the
event's user id if available.

Adding more properties to filter on would certainly be possible.

Regards
Felix

> 
>    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.
> 
> BR,
> 
> Jukka Zitting


Mime
View raw message