You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Unico Hommes (Created) (JIRA)" <ji...@apache.org> on 2012/04/10 18:41:17 UTC
[jira] [Created] (JCR-3290) Concurrent add and move can cause
inconsistency
Concurrent add and move can cause inconsistency
-----------------------------------------------
Key: JCR-3290
URL: https://issues.apache.org/jira/browse/JCR-3290
Project: Jackrabbit Content Repository
Issue Type: Bug
Affects Versions: 2.4, 2.2.11
Reporter: Unico Hommes
Priority: Critical
Fix For: 2.2.12, 2.4.2
Attachments: AddMoveTest.patch
The scenario is as follows:
We start out with the following repository structure:
/folder1/node1
/folder2
Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
Session s2 moves /folder1/node1 to /folder2/node1
Session s2 does a save
Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
Session s1 does a save
The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
Attached is a test case that shows that the above scenario leads to an inconsistency.
Also attached is a proposal for a fix. The patch modifies the semantics of NodeStateMerger.MergerContext#isAdded somewhat: it returns true if either the child is in the added set or it is both in the modified set and its parent is the state that is currently being merged. Perhaps the method should be renamed to isAddedTo instead of just isAdded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3290:
------------------------------
Attachment: AddMoveTest.patch
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The patch modifies the semantics of NodeStateMerger.MergerContext#isAdded somewhat: it returns true if either the child is in the added set or it is both in the modified set and its parent is the state that is currently being merged. Perhaps the method should be renamed to isAddedTo instead of just isAdded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3290:
------------------------------
Description:
The scenario is as follows:
We start out with the following repository structure:
/folder1/node1
/folder2
Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
Session s2 moves /folder1/node1 to /folder2/node1
Session s2 does a save
Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
Session s1 does a save
The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
Attached is a test case that shows that the above scenario leads to an inconsistency.
Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
was:
The scenario is as follows:
We start out with the following repository structure:
/folder1/node1
/folder2
Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
Session s2 moves /folder1/node1 to /folder2/node1
Session s2 does a save
Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
Session s1 does a save
The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
Attached is a test case that shows that the above scenario leads to an inconsistency.
Also attached is a proposal for a fix. The patch modifies the semantics of NodeStateMerger.MergerContext#isAdded somewhat: it returns true if either the child is in the added set or it is both in the modified set and its parent is the state that is currently being merged. Perhaps the method should be renamed to isAddedTo instead of just isAdded.
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Bart van der Schans (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart van der Schans reassigned JCR-3290:
----------------------------------------
Assignee: Bart van der Schans
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Assignee: Bart van der Schans
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Unico Hommes (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250949#comment-13250949 ]
Unico Hommes commented on JCR-3290:
-----------------------------------
Replaced the patch with the proposed fix with a slightly improved one that doesn't change the semantics of the MergerContext#added method
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251489#comment-13251489 ]
Bart van der Schans commented on JCR-3290:
------------------------------------------
I would like to merge this in the 2.2 and 2.4 branches. Can somebody else also review this change?
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3290:
------------------------------
Attachment: SISMMerge.patch
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerge.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The patch modifies the semantics of NodeStateMerger.MergerContext#isAdded somewhat: it returns true if either the child is in the added set or it is both in the modified set and its parent is the state that is currently being merged. Perhaps the method should be renamed to isAddedTo instead of just isAdded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251488#comment-13251488 ]
Bart van der Schans commented on JCR-3290:
------------------------------------------
Committed in trunk in revision 1324713 with trivial adjustments to the patch. Thx Unico!
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256418#comment-13256418 ]
Bart van der Schans commented on JCR-3290:
------------------------------------------
Merged in the 2.4 branch in revision 1327439.
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Assignee: Bart van der Schans
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-3290:
-------------------------------
Fix Version/s: (was: 2.6)
2.5
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Assignee: Bart van der Schans
> Priority: Critical
> Fix For: 2.2.12, 2.4.2, 2.5
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3290:
------------------------------
Attachment: SISMMerger.patch
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Bart van der Schans (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart van der Schans resolved JCR-3290.
--------------------------------------
Resolution: Fixed
Fix Version/s: 2.6
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Assignee: Bart van der Schans
> Priority: Critical
> Fix For: 2.2.12, 2.4.2, 2.6
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256557#comment-13256557 ]
Bart van der Schans commented on JCR-3290:
------------------------------------------
Merged in the 2.2 branch in revision 1327476.
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Assignee: Bart van der Schans
> Priority: Critical
> Fix For: 2.2.12, 2.4.2, 2.6
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3290) Concurrent add and move can cause
inconsistency
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3290:
------------------------------
Attachment: (was: SISMMerge.patch)
> Concurrent add and move can cause inconsistency
> -----------------------------------------------
>
> Key: JCR-3290
> URL: https://issues.apache.org/jira/browse/JCR-3290
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: AddMoveTest.patch, SISMMerger.patch
>
>
> The scenario is as follows:
> We start out with the following repository structure:
> /folder1/node1
> /folder2
> Session s1 modifies /folder1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for /folder1)
> Session s2 moves /folder1/node1 to /folder2/node1
> Session s2 does a save
> Session s1 modifies /folder2/node1 (for instance set a property or add a node, it doesn't matter, as long as it creates a transient item state for node2)
> Session s1 does a save
> The repository is now inconsistent: /folder1 has a child node entry for node1 whereas node1 has parent id for /folder2
> The problem is in the NodeStateMerger.merge method. When on s1.save a merge is attempted on the child node entries of /folder1 the transient state has a child node entry for node1 (which was actually moved to /folder2). This expected. The merger decides to add this node if one of two conditions is true: the child node entry is either in the added set of the change log or it is in the modified set of the change log (the latter because the child node will be in the modified set if it was moved to this node). The latter condition is the problem. Because node1 was modified it is indeed in the modified set and thus added.
> However it has a different parent id (the parent id of the folder it was moved to). That means that /folder1 is saved with a child node entry for node1.
> Attached is a test case that shows that the above scenario leads to an inconsistency.
> Also attached is a proposal for a fix. The fix checks whether the child node entry to be added actually has the state that is currently being merged as its parent and only adds it when it does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira