You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Stefan Rinner (JIRA)" <ji...@apache.org> on 2007/06/29 18:39:04 UTC
[jira] Created: (JCR-993) corrupted paths after moving nodes
corrupted paths after moving nodes
----------------------------------
Key: JCR-993
URL: https://issues.apache.org/jira/browse/JCR-993
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.3
Reporter: Stefan Rinner
we just found a bug which corrupts the results of Node.getPath() - it seems to be related to older Jackrabbit bugs (e.g. JCR-768) but still happens in jackrabbit 1.3 and jackrabbit-1.4-SNAPSHOT
Basically we have a node with 3 subnodes (a, b, c), we move all of them to index 1 - this works fine, unless we call getPath() of the third Node before moving it.
The expected paths after moving would be:
a: /pages[37]/page/element[3]
b: /pages[37]/page/element[2]
c: /pages[37]/page/element
But we get these paths:
a: /pages[37]/page/element[3]
b: /pages[37]/page/element
c: /pages[37]/page/element
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-993) corrupted paths after moving nodes
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-993:
------------------------------
Component/s: core
Fix Version/s: 1.3.1
Merged to the 1.3 branch in revision 552544.
> corrupted paths after moving nodes
> ----------------------------------
>
> Key: JCR-993
> URL: https://issues.apache.org/jira/browse/JCR-993
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.3
> Reporter: Stefan Rinner
> Assignee: Dominique Pfister
> Fix For: 1.3.1
>
> Attachments: JackrabbitPathProb.java
>
>
> we just found a bug which corrupts the results of Node.getPath() - it seems to be related to older Jackrabbit bugs (e.g. JCR-768) but still happens in jackrabbit 1.3 and jackrabbit-1.4-SNAPSHOT
> Basically we have a node with 3 subnodes (a, b, c), we move all of them to index 1 - this works fine, unless we call getPath() of the third Node before moving it.
> The expected paths after moving would be:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element[2]
> c: /pages[37]/page/element
> But we get these paths:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element
> c: /pages[37]/page/element
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-993) corrupted paths after moving nodes
Posted by "Stefan Rinner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509537 ]
Stefan Rinner commented on JCR-993:
-----------------------------------
have been running my fuzz test with the new jackrabbit version and the tests ran through
thanks for the prompt bugfix
> corrupted paths after moving nodes
> ----------------------------------
>
> Key: JCR-993
> URL: https://issues.apache.org/jira/browse/JCR-993
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Stefan Rinner
> Assignee: Dominique Pfister
> Attachments: JackrabbitPathProb.java
>
>
> we just found a bug which corrupts the results of Node.getPath() - it seems to be related to older Jackrabbit bugs (e.g. JCR-768) but still happens in jackrabbit 1.3 and jackrabbit-1.4-SNAPSHOT
> Basically we have a node with 3 subnodes (a, b, c), we move all of them to index 1 - this works fine, unless we call getPath() of the third Node before moving it.
> The expected paths after moving would be:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element[2]
> c: /pages[37]/page/element
> But we get these paths:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element
> c: /pages[37]/page/element
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-993) corrupted paths after moving nodes
Posted by "Stefan Rinner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Rinner updated JCR-993:
------------------------------
Attachment: JackrabbitPathProb.java
simple testcase
> corrupted paths after moving nodes
> ----------------------------------
>
> Key: JCR-993
> URL: https://issues.apache.org/jira/browse/JCR-993
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Stefan Rinner
> Attachments: JackrabbitPathProb.java
>
>
> we just found a bug which corrupts the results of Node.getPath() - it seems to be related to older Jackrabbit bugs (e.g. JCR-768) but still happens in jackrabbit 1.3 and jackrabbit-1.4-SNAPSHOT
> Basically we have a node with 3 subnodes (a, b, c), we move all of them to index 1 - this works fine, unless we call getPath() of the third Node before moving it.
> The expected paths after moving would be:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element[2]
> c: /pages[37]/page/element
> But we get these paths:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element
> c: /pages[37]/page/element
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-993) corrupted paths after moving nodes
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister resolved JCR-993.
-----------------------------------
Resolution: Fixed
As stated previously, caching a path to a child whose parent is currently being modified (or transient) leads to this problem and subsequent changes are hardly detectable. I therefore added a check to the CHM and verified that the testcase now passes.
Fixed in revision 552445.
> corrupted paths after moving nodes
> ----------------------------------
>
> Key: JCR-993
> URL: https://issues.apache.org/jira/browse/JCR-993
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Stefan Rinner
> Assignee: Dominique Pfister
> Attachments: JackrabbitPathProb.java
>
>
> we just found a bug which corrupts the results of Node.getPath() - it seems to be related to older Jackrabbit bugs (e.g. JCR-768) but still happens in jackrabbit 1.3 and jackrabbit-1.4-SNAPSHOT
> Basically we have a node with 3 subnodes (a, b, c), we move all of them to index 1 - this works fine, unless we call getPath() of the third Node before moving it.
> The expected paths after moving would be:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element[2]
> c: /pages[37]/page/element
> But we get these paths:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element
> c: /pages[37]/page/element
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-993) corrupted paths after moving nodes
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister reassigned JCR-993:
-------------------------------------
Assignee: Dominique Pfister
> corrupted paths after moving nodes
> ----------------------------------
>
> Key: JCR-993
> URL: https://issues.apache.org/jira/browse/JCR-993
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Stefan Rinner
> Assignee: Dominique Pfister
> Attachments: JackrabbitPathProb.java
>
>
> we just found a bug which corrupts the results of Node.getPath() - it seems to be related to older Jackrabbit bugs (e.g. JCR-768) but still happens in jackrabbit 1.3 and jackrabbit-1.4-SNAPSHOT
> Basically we have a node with 3 subnodes (a, b, c), we move all of them to index 1 - this works fine, unless we call getPath() of the third Node before moving it.
> The expected paths after moving would be:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element[2]
> c: /pages[37]/page/element
> But we get these paths:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element
> c: /pages[37]/page/element
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-993) corrupted paths after moving nodes
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509524 ]
Dominique Pfister commented on JCR-993:
---------------------------------------
Hi Stefan,
Thank you for reporting this nasty bug in the CachingHierarchyManager (CHM) and providing a testcase that makes it really easy to reproduce what happens underneath. I found the problem to be the following: initially the ordering of elements is as follows:
T1: a b c
You then reorder a before a (which is a no-op) and b before a. This results in:
T2: b a c
At this point, b's path is retrieved and the CHM caches it as the first element in the list. You finally move c before b:
T3: c b a
The CHM will receive a notification about this reordering, and retrieve the list of reordered child node entries. Since b did not change its position compared to T1 (which is the last state that was persisted) the change in b's index passes unnoticed.
> corrupted paths after moving nodes
> ----------------------------------
>
> Key: JCR-993
> URL: https://issues.apache.org/jira/browse/JCR-993
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Stefan Rinner
> Assignee: Dominique Pfister
> Attachments: JackrabbitPathProb.java
>
>
> we just found a bug which corrupts the results of Node.getPath() - it seems to be related to older Jackrabbit bugs (e.g. JCR-768) but still happens in jackrabbit 1.3 and jackrabbit-1.4-SNAPSHOT
> Basically we have a node with 3 subnodes (a, b, c), we move all of them to index 1 - this works fine, unless we call getPath() of the third Node before moving it.
> The expected paths after moving would be:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element[2]
> c: /pages[37]/page/element
> But we get these paths:
> a: /pages[37]/page/element[3]
> b: /pages[37]/page/element
> c: /pages[37]/page/element
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.