[
https://issues.apache.org/jira/browse/OAK-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616391#comment-14616391
]
Stefan Egli commented on OAK-2131:
----------------------------------
Just for the record: this OAK-2131 results in the LastRevRecoveryAgent to
potentially update child nodes and not the parent/root node, like so (this is
from a manual test):
{code}
11:04:52.747 INFO [lastRevThread[cid=1]] LastRevRecoveryAgent.java:248 Updated
lastRev of [3] documents while performing lastRev recovery for cluster node
[2]: {/2/stuffForRecovery=r14e67c2b522-0-2, /2/2=r14e67c2b44c-0-2,
/2/2/57=r14e67c2b44c-0-2}
{code}
The odd thing at first glance is that you'd expect the LastRevRecoveryAgent to
always update the root whenever i has to update a child wrt the {{_lastRev}}.
But that's not the case as with OAK-2131 the {{Commit}} does not always update
the {{_lastRev}}, eg for nodes that have content changes. Afaics the behavior
is still correct though, the only misleading part is the log message above.
(/cc [~mreutegg]: fyi)
> Reduce usage of _lastRev
> ------------------------
>
> Key: OAK-2131
> URL: https://issues.apache.org/jira/browse/OAK-2131
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mongomk
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Fix For: 1.1.3
>
> Attachments: OAK-2131.patch
>
>
> As described in OAK-1768 the usage of _lastRev must be reduced to better
> handle large transaction. The short term solution implemented for OAK-1768
> relies on MapDB to temporarily store the pending modifications to a temp
> file. This solution prevents an OOME when there is a large commit, but can
> take quite a while to update the _lastRev fields after the branch is merged.
> This has an impact on the visibility of changes in a cluster because any
> further changes done after the merge only become visible when the large
> update of the _lastRev fields went through.
> Delayed propagation of changes can become a problem in a cluster when some
> components rely on a timely visibility of changes. One example is the Apache
> Sling Topology, which sends heartbeats through the cluster by updating
> properties in the repository. The topology implementation will consider a
> cluster node dead if those updates are not propagated in the cluster within a
> given timeout. Ultimately this may lead to a cluster with multiple leaders.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
