jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart van der Schans (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3291) Stack overflow in multi-session test with moves
Date Wed, 18 Apr 2012 09:36:37 GMT

    [ https://issues.apache.org/jira/browse/JCR-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256385#comment-13256385

Bart van der Schans commented on JCR-3291:

The real problem is not the stack overflow. That's just a result of a cyclic path which should
not have been created in the first place.

The problem occurs when session2 fetches node a, *after* it's on move operation. It will get
the updated node and hence a cyclic (transient) path is created. The only way to prevent this
from happening is to create transient item states of all parents of the destination node.
Then session2 will still see node a as child of the test root after the save of session1 happens.
The save operation itself fails correctly with a StaleItemStateException.
> Stack overflow in multi-session test with moves
> -----------------------------------------------
>                 Key: JCR-3291
>                 URL: https://issues.apache.org/jira/browse/JCR-3291
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>            Reporter: Frank van Lankvelt
>            Assignee: Bart van der Schans
>             Fix For: 2.2.12, 2.4.2
>         Attachments: JCR-3291-test.patch, JCR-3291.patch
> When two sessions move nodes in incompatible ways (see test), the hierarchy manager can
get into an infinite recursion when building paths.
> Setup: nodes /a/aa & /b.
> // results in /b/a/aa
> session1.move(testRootPath + "/a", testRootPath + "/b/a");
> // results in aa/b/aa/b/aa/b/aa/etc.
> session2.move(testRootPath + "/b", testRootPath + "/a/aa/b");
> session1.save();
> session2.save();
> The problem arises when the hierarchy manager uses a mix of transient states and unmodified
states managed by the local item state manager.
> When session 1 is saved, the state change of node a is dispatched to session 2.  Node
"a" is not changed in session 2, so it's new shared state will be used as-is.
> It will have parent "b" according to the hierarchy manager in session 2.
> The proposed solution is to keep track of the nodes that have been used in building up
the path.  This has the downside that building up paths becomes more expensive.
> I haven't done any performance measurements yet on the impact of the change.  If performance
is an issue, perhaps the implementation can be limited to the case that the consistencyCheckEnabled
flag is set.

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


View raw message