[
https://issues.apache.org/jira/browse/OAK-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922844#comment-13922844
]
Jukka Zitting commented on OAK-1497:
------------------------------------
Some other alternatives:
7. Make the change queue size configurable, so a deployment can choose a value
like 1M to simulate the crx2 behavior of hitting an OOME before the isExternal
compression kicks in. :-)
8. Add a commit hook that blocks local commits if the queue is full. Only once
the listener catches up with the backlog would new local commits be allowed.
Option 8 illustrates the fundamental tradeoff we're dealing with here. If an
observation listener is unable to process events at the same rate or faster
than they are being generated, the system needs to queue events to keep the
listener contract. Ultimately an OOME will result unless we either throw away
some information (like is done with the isExternal compression) or prevent more
events to be generated after some predefined limit has been reached.
> JackrabbitEvent#isExternal() returns true for internal changes for slow
> listeners
> ---------------------------------------------------------------------------------
>
> Key: OAK-1497
> URL: https://issues.apache.org/jira/browse/OAK-1497
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Fix For: 0.19
>
>
> Oak degrades gracefully for observation listeners that can't keep up with the
> rate of observation events fired. See {{BackgroundObserver#contentChanged}}
> for the gory details.
> As a side effect {{JackrabbitEvent#isExternal}} will always return {{true}}
> when this degradation happens. However there is currently no way for clients
> to detect this and to thus know whether the result of
> {{JackrabbitEvent#isExternal}} is reliable or not.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
