[
https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1133:
-------------------------------
Labels: observation performance (was: performance)
> 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: observation, performance
> Fix For: 0.12
>
>
> 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)
