[jira] [Updated] (OAK-1133) Observation listener PLUS

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Klimetschek updated OAK-1133:
---------------------------------------

    Description: 
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}})

  was:
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}})


> 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, 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)