You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2014/12/08 14:15:12 UTC

[jira] [Resolved] (OAK-2131) Reduce usage of _lastRev

     [ https://issues.apache.org/jira/browse/OAK-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Reutegger resolved OAK-2131.
-----------------------------------
       Resolution: Fixed
    Fix Version/s:     (was: 1.0.9)
                       (was: 1.2)
                   1.1.3

Applied a slightly cleaned up version of the patch to trunk: http://svn.apache.org/r1643808

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