[ https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826317#comment-13826317 ]
Michael Dürig commented on OAK-1133: ------------------------------------ * At http://svn.apache.org/r1543077 I added some generic classes and interfaces for event filtering and generation. These should be generic enough to implement standard JCR observation, observation PLUS as described in this issue, more a more tight integration into Sling like we are discussion in OAK-1120 and integration with the [OSGi EventAdmin service | http://markmail.org/message/5g5kl6as4c2hqfgf]. * At http://svn.apache.org/r1543079 I added some filter implementations specific to JCR observation * At http://svn.apache.org/r1543080 I implemented JCR observation using the new classes and interfaces from above. > Observation listener PLUS > ------------------------- > > Key: OAK-1133 > URL: https://issues.apache.org/jira/browse/OAK-1133 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: commons, jcr > Reporter: Alexander Klimetschek > Assignee: Michael Dürig > Labels: observation, performance > Fix For: 0.13 > > > Oak should provide an *extended and efficient JCR observation listener* > mechanism to support common use cases not handled well by the restricted > options of the JCR observation (only base path, node types and raw events). > Those cases require listeners to register much more broadly and then filter > out their specific cases themselves, thus putting too many events into the > observation system and creating a huge overhead due to asynchronous access to > the modified JCR data to do the filtering. This easily is a big performance > bottleneck with many writes and thus many events. > Previous discussions [on the > list|http://markmail.org/message/oyq7fnfrveceemoh] and in OAK-1120, and > [latest discussion on the list|http://markmail.org/message/x2l6tv4m7bxjzqqq]. > The goals should be: > * performance: handle filtering as early as possible, during the commit, > where access to the modified data is already present > * provide robust implementation for typical filtering cases > * provide an asynchronous listener mechanism as in JCR > * minimize effect on the lower levels on Oak (a visible addition in > oak-commons or oak-jcr should be enough) > * for delete events, allow filtering on the to-be-deleted data (currently not > possible in jcr listeners that run after the fact) > * ignore external cluster events by default; have an extra option if you > really want to register for external events > * if possible: design as an extension of the jcr observation to simplify > migration for existing code > * if possible: provide an intelligent listener that can work with pure JCR > (aka Jackrabbit 2) as well, by falling back to in-listener-filtering > * maybe: synchronous option using the same simple interface (instead of raw > Oak plugins itself); however, not sure if there is a benefit if they can only > read data and not change or block the session commit > Typical filtering cases: > - 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 > - check for any parent/ancestor as well (e.g. change deep inside a node type > = foo structure should be triggered, even if the node with the type wasn't > modified; very important to support efficiently) > - node types (already in jcr observation) > - created/modified/deleted events, separate from move/copy > - and more... a custom filter should be possible to pass through (with > similar access as the {{Observer}}) -- This message was sent by Atlassian JIRA (v6.1#6144)