[ https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870191#comment-13870191 ]
Alexander Klimetschek commented on OAK-1133: -------------------------------------------- Here are some ideas I once had for performance tests wrt observation listeners (adding here to at least persist the idea): - "real world": many listeners (200+), with multiple parallel writes - external events - slow, badly implemented listener (random sleep or many jcr read operations) - compare in-listener filtering w/ early filtering > 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.14 > > > 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.5#6160)