jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Fri, 25 Oct 2013 21:11:26 GMT
Hi,

IMHO it would be nice to support more matching functionality for events down in Oak. See my
mail on the Sling thread [0].

The general advantage would be that for non-matches there would be no event created at all,
no thread started and what else is involved. I assume that could happen most efficiently in
the diff of the editing session already (or similar).

The use cases are (taken from the Adobe CQ workflow launcher, should overlap with Sling's
jcr listener):
- paths with globbing support (for example /content/foo/*/something)
- check for property values (equal, not equal, contains etc.), most importantly sling:resourceType
in Sling apps
- allow to check properties on child nodes as well, typically jcr:content
- node types (already in jcr observation)
- created/modified/deleted events, separate from move/copy

Regarding move events, afaiu you often want to filter them out, to avoid reprocessing things
if the contents of a node tree didn't actually change but just moved around. So having a created/modified
event that does not get triggered by a move or copy would be required. (Probably repeating
here, just wanted to clarify).

Maybe it would be useful to additionally allow a generic "matches" function that can be passed
upon listener registration that could check whatever it wants, working on the diff or change
set directly. Of course one would have to program it carefully to make sure it's fast, but
at least it would run as early as possible.

Still, the common things like check on property etc. should be pre-implemented to avoid every
listener having to come up with its own.

Maybe this can all be seen as a custom extension to Oak, but it would make sense to standardize
it, since it is so common. Also, the part where the listener is triggered probably involves
some thread work that should definitely not be left to the application level.

WDYT?

[0] http://markmail.org/message/dvs2o5p5x45fjyxy (and following)

Cheers,
Alex

On 25.10.2013, at 06:14, Angela Schreiber <anchela@adobe.com> wrote:

> hi bertrand
> 
> +1 for everything you said.
> 
> in general i think that we have split that section in the docu:
> 
> a) summary from OAK point of view (for those that know the very details)
> b) summary from a JCR/Jackrabbit point of view. IMHO we can't expect
>   our user community to understand how these subtle differences
>   affect the behaviour of the JCR implementation and the event handling.
>   a more comprehensive list would IMO make sense in order to allow
>   users to get a feeling what they can expect.
> 
> in general i am sure michael has the best overview as he is
> implementing observation in OAK and knows best which cases will
> work and where the differences are. afaik he is also a sling
> committer :-)
> 
> kind regards
> angela
> 
> 
> 
> On 10/25/13 2:37 PM, "Bertrand Delacretaz" <bdelacretaz@apache.org> wrote:
> 
>> Hi Angela,
>> 
>> On Fri, Oct 25, 2013 at 11:21 AM, Angela Schreiber <anchela@adobe.com>
>> wrote:
>>> Bertrand wrote:
>>>> The OSGi events that Sling rebroadcasts are less granular than JCR
>>>> events, so this might not be a problem for that case.
>>> 
>>> do you know it or are you guessing?...
>> 
>> I'm making an educated guess.
>> 
>> To get hard facts, as you rightly ask for, we need a test suite that
>> compares those OSGi events that Sling rebroadcasts, when doing various
>> things on Jackrabbit and Oak. I don't think we'll ever get 100%
>> identical observation behavior between Jackrabbit and Oak, so we'll
>> need to define which differences are acceptable. To me the only sane
>> way to do that is via a test suite.
>> 
>> This can be added to the Sling it-jackrabbit-oak module [1] which
>> makes it easy to run the exact same tests against Jackrabbit and Oak
>> in an OSGi environment, but someone will need to write those tests. We
>> might want to grant write access to both Sling + Oak committers to
>> that module to make things easier.
>> 
>> Thanks for the examples that you mention. I see the referenceable node
>> issue at http://jackrabbit.apache.org/oak/docs/differences.html, but
>> not the setPrimaryType one, could it be added?
>> 
>> Ciao,
>> -Bertrand
>> 
>> [1] 
>> http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/it-jackrabbit-oak/
> 


Mime
View raw message