jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-1133) Observation listener PLUS
Date Tue, 19 Nov 2013 09:09:22 GMT

    [ https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826333#comment-13826333
] 

Michael Dürig commented on OAK-1133:
------------------------------------

Adding dependency to OAK-190 as we could leverage {{javax.jcr.observation.EventFilter}} from
JCR 2.1 to inject custom filters.

> 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.13
>
>
> 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)

Mime
View raw message