jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 13:43:10 GMT
Sling's jcr listener provides an API/contract - so this is an
infrastructure component used by application code (or other infrastructure
code). And as the listener is delegating the promotion of events to the
EventAdmin, the jcr listener does not know if there are event listeners at
all or what kind of events they are interested in. And most OSGI event
listeners listen for all modification events and do their own filtering.
The event send out by the listener contains additional information like the
resource type, that's why the listener is reading every created / changed
node.
This is the contract we have to maintain in Sling.

Carsten


2013/10/22 Jukka Zitting <jukka.zitting@gmail.com>

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



-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message