[
https://issues.apache.org/jira/browse/OAK-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15770264#comment-15770264
]
Marcel Reutegger commented on OAK-5337:
---------------------------------------
The change looks good to me. Can you please also update the JavaDoc for the
method and clarify that the local clusterId is never considered as candidate
even if the lease timed out? The test gets stuck because it doesn't clean up
properly. The test should dispose the fixture in the after method:
{noformat}
@After
- public void tearDown(){
+ public void tearDown() throws Exception {
ds1.dispose();
ds2.dispose();
sharedStore.dispose();
+ fixture.dispose();
ClusterNodeInfo.resetClockToDefault();
Revision.resetClockToDefault();
}
{noformat}
With this change the test ran fine on my machine. With proper clean up the
first lines of the new test method can probably be changed as well.
> LastRevRecoveryAgent should avoid recovering documents from its own cluster
> id if the instance is running
> ---------------------------------------------------------------------------------------------------------
>
> Key: OAK-5337
> URL: https://issues.apache.org/jira/browse/OAK-5337
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
> Reporter: Vikas Saurabh
> Assignee: Vikas Saurabh
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Attachments: OAK-5337.patch
>
>
> In certain scenarios (mostly slow background write leading to lease timeout),
> last rev recovery agent can kick in and start to recover documents from its
> own cluster id. The situation is implicitly avoided in 1.4+ (OAK-3397) as the
> instance would kill itself on lease failure (there are other safeguards too
> to avoid the situation). But, on older branches, especially 1.0 which has no
> safeguards, this can lead to loss of last revs.
> All that said, it's anyway reasonable that LRRA shouldn't try to recover its
> own instance while it's running (startup still needs to be handled by LRRA
> though).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
