[
https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810093#comment-13810093
]
Bertrand Delacretaz commented on OAK-1133:
------------------------------------------
>From the discussions on list it looks like aggregating events from all the
>nodes in a cluster makes scalability difficult, IIUC.
If that's correct, having the option to use an external distribution mechanism
(JMS message queues come to mind) to aggregate cluster events is acceptable
IMO, for cases that require high scalability. Oak could provide a usable
aggregation out of the box, and allow users to move to a more scalable
mechanism where needed.
> 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)
> * 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
> - 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)
