[jira] [Updated] (OAK-3079) LastRevRecoveryAgent can update _lastRev of children but not the root
[ https://issues.apache.org/jira/browse/OAK-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3079: -- Labels: resilience (was: candidate_oak_1_2 resilience) Fix Version/s: 1.2.17 Merged into 1.2 branch: http://svn.apache.org/r1751238 > LastRevRecoveryAgent can update _lastRev of children but not the root > - > > Key: OAK-3079 > URL: https://issues.apache.org/jira/browse/OAK-3079 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.2, 1.3.2 >Reporter: Stefan Egli >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.4, 1.3.5, 1.2.17 > > Attachments: NonRootUpdatingLastRevRecoveryTest.java > > > As mentioned in > [OAK-2131|https://issues.apache.org/jira/browse/OAK-2131?focusedCommentId=14616391=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14616391] > there can be a situation wherein the LastRevRecoveryAgent updates some nodes > in the tree but not the root. This seems to happen due to OAK-2131's change > in the Commit.applyToCache (where paths to update are collected via > tracker.track): in that code, paths which are non-root and for which no > content has changed (and mind you, a content change includes adding _deleted, > which happens by default for nodes with children) are not 'tracked', ie for > those the _lastRev is not update by subsequent backgroundUpdate operations - > leaving them 'old/out-of-date'. This seems correct as per > description/intention of OAK-2131 where the last revision can be determined > via the commitRoot of the parent. But it has the effect that the > LastRevRecoveryAgent then finds those intermittent nodes to be updated while > as the root has already been updated (which is at first glance non-intuitive). > I'll attach a test case to reproduce this. > Perhaps this is a bug, perhaps it's ok. [~mreutegg] wdyt? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3079) LastRevRecoveryAgent can update _lastRev of children but not the root
[ https://issues.apache.org/jira/browse/OAK-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3079: -- Affects Version/s: 1.2 LastRevRecoveryAgent can update _lastRev of children but not the root - Key: OAK-3079 URL: https://issues.apache.org/jira/browse/OAK-3079 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 1.2, 1.3.2 Reporter: Stefan Egli Assignee: Marcel Reutegger Labels: resilience Fix For: 1.3.6 Attachments: NonRootUpdatingLastRevRecoveryTest.java As mentioned in [OAK-2131|https://issues.apache.org/jira/browse/OAK-2131?focusedCommentId=14616391page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14616391] there can be a situation wherein the LastRevRecoveryAgent updates some nodes in the tree but not the root. This seems to happen due to OAK-2131's change in the Commit.applyToCache (where paths to update are collected via tracker.track): in that code, paths which are non-root and for which no content has changed (and mind you, a content change includes adding _deleted, which happens by default for nodes with children) are not 'tracked', ie for those the _lastRev is not update by subsequent backgroundUpdate operations - leaving them 'old/out-of-date'. This seems correct as per description/intention of OAK-2131 where the last revision can be determined via the commitRoot of the parent. But it has the effect that the LastRevRecoveryAgent then finds those intermittent nodes to be updated while as the root has already been updated (which is at first glance non-intuitive). I'll attach a test case to reproduce this. Perhaps this is a bug, perhaps it's ok. [~mreutegg] wdyt? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3079) LastRevRecoveryAgent can update _lastRev of children but not the root
[ https://issues.apache.org/jira/browse/OAK-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-3079: --- Fix Version/s: (was: 1.4) 1.3.6 LastRevRecoveryAgent can update _lastRev of children but not the root - Key: OAK-3079 URL: https://issues.apache.org/jira/browse/OAK-3079 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 1.3.2 Reporter: Stefan Egli Labels: resilience Fix For: 1.3.6 Attachments: NonRootUpdatingLastRevRecoveryTest.java As mentioned in [OAK-2131|https://issues.apache.org/jira/browse/OAK-2131?focusedCommentId=14616391page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14616391] there can be a situation wherein the LastRevRecoveryAgent updates some nodes in the tree but not the root. This seems to happen due to OAK-2131's change in the Commit.applyToCache (where paths to update are collected via tracker.track): in that code, paths which are non-root and for which no content has changed (and mind you, a content change includes adding _deleted, which happens by default for nodes with children) are not 'tracked', ie for those the _lastRev is not update by subsequent backgroundUpdate operations - leaving them 'old/out-of-date'. This seems correct as per description/intention of OAK-2131 where the last revision can be determined via the commitRoot of the parent. But it has the effect that the LastRevRecoveryAgent then finds those intermittent nodes to be updated while as the root has already been updated (which is at first glance non-intuitive). I'll attach a test case to reproduce this. Perhaps this is a bug, perhaps it's ok. [~mreutegg] wdyt? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3079) LastRevRecoveryAgent can update _lastRev of children but not the root
[ https://issues.apache.org/jira/browse/OAK-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-3079: --- Labels: resilience (was: ) LastRevRecoveryAgent can update _lastRev of children but not the root - Key: OAK-3079 URL: https://issues.apache.org/jira/browse/OAK-3079 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 1.3.2 Reporter: Stefan Egli Labels: resilience Fix For: 1.4 Attachments: NonRootUpdatingLastRevRecoveryTest.java As mentioned in [OAK-2131|https://issues.apache.org/jira/browse/OAK-2131?focusedCommentId=14616391page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14616391] there can be a situation wherein the LastRevRecoveryAgent updates some nodes in the tree but not the root. This seems to happen due to OAK-2131's change in the Commit.applyToCache (where paths to update are collected via tracker.track): in that code, paths which are non-root and for which no content has changed (and mind you, a content change includes adding _deleted, which happens by default for nodes with children) are not 'tracked', ie for those the _lastRev is not update by subsequent backgroundUpdate operations - leaving them 'old/out-of-date'. This seems correct as per description/intention of OAK-2131 where the last revision can be determined via the commitRoot of the parent. But it has the effect that the LastRevRecoveryAgent then finds those intermittent nodes to be updated while as the root has already been updated (which is at first glance non-intuitive). I'll attach a test case to reproduce this. Perhaps this is a bug, perhaps it's ok. [~mreutegg] wdyt? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3079) LastRevRecoveryAgent can update _lastRev of children but not the root
[
https://issues.apache.org/jira/browse/OAK-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3079:
-
Attachment: NonRootUpdatingLastRevRecoveryTest.java
Attached [^NonRootUpdatingLastRevRecoveryTest.java] which illustrates what was
described in the ticket. Note that the test succeed - which is why I derive
that this is not a bug. The test produces log info of the following kind:
{code}
17:03:28.848 INFO [main] LastRevRecoveryAgent.java:248 Updated lastRev of
[6] documents while performing lastRev recovery for cluster node [1]:
{/foo/bar/5/6=r14e690b0947-0-1, /foo/bar/5=r14e690b0947-0-1,
/foo/bar/1/2=r14e690b0940-0-1, /foo/bar/1=r14e690b0940-0-1,
/foo/bar/1/2/3=r14e690b0940-0-1, /foo/bar/5/6/7=r14e690b0947-0-1}
{code}
which shows that root was not updated .. to see this, enable logback-test.xml
console logger.
LastRevRecoveryAgent can update _lastRev of children but not the root
-
Key: OAK-3079
URL: https://issues.apache.org/jira/browse/OAK-3079
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, mongomk
Affects Versions: 1.3.2
Reporter: Stefan Egli
Attachments: NonRootUpdatingLastRevRecoveryTest.java
As mentioned in
[OAK-2131|https://issues.apache.org/jira/browse/OAK-2131?focusedCommentId=14616391page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14616391]
there can be a situation wherein the LastRevRecoveryAgent updates some nodes
in the tree but not the root. This seems to happen due to OAK-2131's change
in the Commit.applyToCache (where paths to update are collected via
tracker.track): in that code, paths which are non-root and for which no
content has changed (and mind you, a content change includes adding _deleted,
which happens by default for nodes with children) are not 'tracked', ie for
those the _lastRev is not update by subsequent backgroundUpdate operations -
leaving them 'old/out-of-date'. This seems correct as per
description/intention of OAK-2131 where the last revision can be determined
via the commitRoot of the parent. But it has the effect that the
LastRevRecoveryAgent then finds those intermittent nodes to be updated while
as the root has already been updated (which is at first glance non-intuitive).
I'll attach a test case to reproduce this.
Perhaps this is a bug, perhaps it's ok. [~mreutegg] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
