[
https://issues.apache.org/jira/browse/OAK-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882831#comment-13882831
]
Jukka Zitting commented on OAK-1332:
------------------------------------
bq. Could you elaborate?
The observation code uses {{Tree}} instances only for {{getPath()}} and
{{IdentifierManager.getIdentifier()}}. Both needs could be addressed by
(lazily) tracking the current path and identifier while recursing down the
content diff, so it should be possible to drop the {{Tree}} references entirely.
Also, I'd like to postpone the generation of {{NODE_ADDED}}, {{NODE_MOVED}} and
{{NODE_REMOVED}} events to when that child node gets diffed. Then we'll never
have more than one or two such {{EventImpl}} instances in the queue at a time,
and can focus on the memory impact of the child diff continuations.
BTW, while working on the code, it even occurred to me that there would even be
a way to solve this issue entirely. The content diff of a node could keep track
of the number of changes seen so far. Once it reaches some predefined limit, it
would stop the diff and add a continuation that would redo the diff, skip the
changes already seen, and continue generating events from that point. This
should work since the {{NodeState}} interface requires a repeated method call
on the same instances to "produce the same result as before", even down to the
iteration order.
> Large number of changes to the same node can fill observation queue
> -------------------------------------------------------------------
>
> Key: OAK-1332
> URL: https://issues.apache.org/jira/browse/OAK-1332
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Priority: Minor
> Fix For: 0.16
>
>
> Changing, adding or removing a lot of (10'000s or more) direct children of
> node with on save() might cause observation queues to fill up.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
