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