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

Stefan Egli commented on OAK-1368:
----------------------------------

Once OAK-4796 will be resolved we'll have a setup where during the commit a 
ChangeSet will be populated with paths, names, properties, node types and this 
can be used by the event filter to have a fast 'am I at all possibly interested 
in this commit'. So this should reduce number of commits that later 
asynchronously need to be processed by the event filter.

Re the fixed limit on event queues: for that I think OAK-4581 (persisting 
events) comes into play: depending on how exactly we'll solve that there will 
be a threshold for the queue length after which events will be persisted. This 
results in virtually unlimited event queues, thus supports slow listeners as 
well as avoids running out of heap.

[~mduerig], were you referring to those 2 issues I guess?

> 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
>
> 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.3.4#6332)

Reply via email to