[
https://issues.apache.org/jira/browse/OAK-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-5337.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.6
1.5.17
Done on trunk at [r1775757|https://svn.apache.org/r1775757]. Thanks [~mreutegg]
for the review and for fixing the issue with test that I was having. I've
updated the javadoc.
[~chetanm], the fix failed
{{LastRevSingleNodeRecoveryTest#testNodeRecoveryNeeded}} as it was expecting
self-node to be part of candidate list to be recovered (which is opposite of
the expectation in this issue). I've updated that test to validate that
{{isRecoveryNeeded}} is still true while recovery candidate list is empty.
> 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
> Fix For: 1.5.17, 1.6
>
> 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)
