jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Süß <dominik.su...@gmail.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 14:32:20 GMT
Hi :)

Speaking as developer using the Sling eventing I just wanted to add that in
most cases there are restrictions on Paths (most times not just one but
multiple "searchpaths") and on a resourceType (not just exact match but a
set or pattern to identify a set of resourceTypes) and in some occasions
further constraints like existance or a specific value of a specific
property. Currently it is up to the user to do this check within the
EventListener, but I think it would be feasible to register a listener that
defines those checks that can be processed by the implementation at a low
level. But it would be good to ask around in the sling community how these
events are used in production to be sure not to miss essential patterns.


On Tue, Oct 22, 2013 at 4:20 PM, Jukka Zitting <jukka.zitting@gmail.com>wrote:

> Hi,
> On Tue, Oct 22, 2013 at 9:59 AM, Felix Meschberger <fmeschbe@adobe.com>
> wrote:
> > That's one Event object per event -- not one event per listener per
> event.
> > This is completely different to JCR.
> You're mistaking the problem here, it's not the number of listeners,
> it's the number of events *per listener*.
> What we're looking at here is scaling out to write loads that could
> well have over a million changed items per second. On my laptop just
> instantiating a dummy Event object takes a few hundred nanoseconds, so
> there's no way to process millions of them per second in a single
> listener.
> BR,
> Jukka Zitting

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