[jira] [Commented] (OAK-1368) Only one Observer per session

["Michael Dürig (JIRA)" <ji...@apache.org>]

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

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

I implemented a [draft|https://github.com/mduerig/jackrabbit-oak/commits/OAK-1368] of the approach outlined in the 4th bullet point above in my private GitHub fork. As this is a big change I structured it into a couple of commits to make it easier to follow:

* [Piggy back diffing | https://github.com/mduerig/jackrabbit-oak/commit/31981e991ccf815a532d91c7b72c386819a118b1#diff-d41d8cd98f00b204e9800998ecf8427e]: Each session only has a single observer doing a single diff per committed revision. One of the registered listeners will receive the events immediately while the others piggy back on the diff, keep all their events in a queue and dispatch them one by one on the same thread. A challenge with this approach is registering new listeners: as there is only one diff operation off a shared revision queue the queue might still hold revisions from the past for what the new listener is concerned. I added a [callback mechanism | https://github.com/mduerig/jackrabbit-oak/blob/31981e991ccf815a532d91c7b72c386819a118b1/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/BackgroundObserver.java#L194] to the background observer to defer the actual registration of the listener until the revision queue is at the right revision. 

* [Fixed limit on event queues | https://github.com/mduerig/jackrabbit-oak/commit/f6e8d721a6230fb399cba94cc347620a498a4787#diff-d41d8cd98f00b204e9800998ecf8427e]: Event queues of piggy back listeners overflow after a fixed number of events. Listeners for which this happens will simply be tried again in a [divide and conquer | https://github.com/mduerig/jackrabbit-oak/blob/f6e8d721a6230fb399cba94cc347620a498a4787/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ChangeProcessor.java#L330] mode. 

* [Sub tree optimisation | https://github.com/mduerig/jackrabbit-oak/commit/3244002134ec851b70758748caa06d23f8f0f76f#diff-d41d8cd98f00b204e9800998ecf8427e]: Diff as few sub trees as possible by looking into the path constraints of all the filters of all the listeners. 

* [Memory sensitive event queue | https://github.com/mduerig/jackrabbit-oak/commit/0a2f187aacce3b365124c84a644389717764efb8#diff-d41d8cd98f00b204e9800998ecf8427e]: Instead of having the event queues overflow after a fixed number of events, make them overflow once heap becomes scarce. This will result in a runtime trade off of memory vs. CPU: fall back to diffing if there is not enough memory to hold all the events. 

> Only one Observer per session
> -----------------------------
>
>                 Key: OAK-1368
>                 URL: https://issues.apache.org/jira/browse/OAK-1368
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: jcr
>            Reporter: Jukka Zitting
>            Assignee: Michael Dürig
>              Labels: observation
>             Fix For: 1.1, 1.0.5
>
>
> As mentioned in OAK-1332, a case where a single session registers multiple observation listeners can be troublesome if events are delivered concurrently to all of those listeners, since in such a case the {{NamePathMapper}} and other session internals will likely suffer from lock contention.
> A good way to avoid this would be to have all the listeners registered within a single session be tied to a single {{Observer}} and thus processed sequentially.
> Doing so would also improve performance as the listeners could leverage the same content diff. As the listeners come from a single session and thus presumably from a single client, there's no need to worry about one client blocking the work of another.



--
This message was sent by Atlassian JIRA
(v6.2#6252)