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

Stefan Egli edited comment on OAK-2131 at 7/7/15 9:49 AM:
----------------------------------------------------------

bq. Or do you mean it does actually happen, but when LastRevRecoveryAgent is 
triggered, it updates _lastRevs that aren't really necessary?
yes. The root is updated at an earlier stage since {{Commit}} does not filter 
out the root (and parents that have no content changes). So as I understand the 
rational behind OAK-2131 it tries to reduce the number of {{_lastRev}} changes 
by using the fact that if there is a content change that will be visible in the 
parent anyway via the commitRoot - so it is using that instead of explicitly 
updating {{_lastRev}}. However, the {{LastRevRecoveryAgent}} does not do this 
optimization (which I think it is correct to not do) and updates all 
{{_lastRev}}s that the {{Commit}} has "optimized-away"
bq.  In any case, can you please file a new issue and provide information about 
how to reproduce? 
yes, I can do that


was (Author: egli):
bq. Or do you mean it does actually happen, but when LastRevRecoveryAgent is 
triggered, it updates _lastRevs that aren't really necessary?
yes. The root is updates at an earlier stage since {{Commit}} does not filter 
out the root (and parents that have no content changes). So as I understand the 
rational behind OAK-2131 it tries to reduce the number of {{_lastRev}} changes 
by using the fact that if there is a content change that will be visible in the 
parent anyway via the commitRoot - so it is using that instead of explicitly 
updating {{_lastRev}}. However, the {{LastRevRecoveryAgent}} does not do this 
optimization (which I think it is correct to not do) and updates all 
{{_lastRev}}s that the {{Commit}} has "optimized-away"
bq.  In any case, can you please file a new issue and provide information about 
how to reproduce? 
yes, I can do that

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

Reply via email to