[ https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813767#comment-13813767 ]
Michael Dürig commented on OAK-1133: ------------------------------------ I think once the suggested refactorings from OAK-1143 are done, it should be quite easy to extend the current observation mechanism to cater of most/all of the requirements listed here and also include things from the patch on OAK-1120 as well as including the {{ExcludeExternal}} semantics from OAK-1121 > 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 > Labels: performance > > 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. > 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)