jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3368) CachingHierarchyManager: inconsistent state after transient changes on root node
Date Sat, 14 Jul 2012 10:31:35 GMT

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

Unico Hommes commented on JCR-3368:
-----------------------------------

It seems that the special handling of the root node has nothing to do with this issue. The
issue seems to be with with removing intermediate paths in general. If you change the test
case to the following it also fails:

        final Session session = getHelper().getSuperuserSession();
        session.getRootNode().addNode("foo").addNode("bar").addNode("qux");
        session.save();
        session.getNode("/foo/bar/qux");
        session.getNode("/foo/bar").remove();
        session.getNode("/foo").hasNode("bar/qux");

Somehow the mapping from /foo to /foo/bar/qux does not get flushed. If I remove the check
whether the id is in the idCache in nodeRemoved method the test passes. 

                
> CachingHierarchyManager: inconsistent state after transient changes on root node 
> ---------------------------------------------------------------------------------
>
>                 Key: JCR-3368
>                 URL: https://issues.apache.org/jira/browse/JCR-3368
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.2.12, 2.4.2, 2.5
>            Reporter: Unico Hommes
>         Attachments: HasNodeAfterRemoveTest.java
>
>
> See attached test case.
> You will see the following exception:
> javax.jcr.RepositoryException: failed to retrieve state of intermediary node
>         at org.apache.jackrabbit.core.CachingHierarchyManager.resolvePath(CachingHierarchyManager.java:156)
>         at org.apache.jackrabbit.core.HierarchyManagerImpl.resolveNodePath(HierarchyManagerImpl.java:372)
>         at org.apache.jackrabbit.core.NodeImpl.getNodeId(NodeImpl.java:276)
>         at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:223)
>         at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2250)
>         at org.apache.jackrabbit.core.HasNodeAfterRemoveTest.testRemove(HasNodeAfterRemoveTest.java:14)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:616)
>         at junit.framework.TestCase.runTest(TestCase.java:168)
>         at junit.framework.TestCase.runBare(TestCase.java:134)
>         at junit.framework.TestResult$1.protect(TestResult.java:110)
>         at junit.framework.TestResult.runProtected(TestResult.java:128)
>         at junit.framework.TestResult.run(TestResult.java:113)
>         at junit.framework.TestCase.run(TestCase.java:124)
>         at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456)
>         at junit.framework.TestSuite.runTest(TestSuite.java:243)
>         at junit.framework.TestSuite.run(TestSuite.java:238)
>         at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
>         at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>         at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
>         at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:616)
>         at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
>         at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> Caused by: org.apache.jackrabbit.core.state.NoSuchItemStateException: c7ccbcd3-0524-4d4d-a109-eae84627f94e
>         at org.apache.jackrabbit.core.state.SessionItemStateManager.getTransientItemState(SessionItemStateManager.java:304)
>         at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:153)
>         at org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(HierarchyManagerImpl.java:152)
>         at org.apache.jackrabbit.core.HierarchyManagerImpl.resolvePath(HierarchyManagerImpl.java:115)
>         at org.apache.jackrabbit.core.CachingHierarchyManager.resolvePath(CachingHierarchyManager.java:152)
>         ... 29 more
> I tried several things to fix this but didn't find a better solution than to just wrap
the statement
> NodeId id = resolveRelativeNodePath(relPath);
> in a try catch RepositoryException and return false when that exception occurs.
> In particular I tried changing the implementation to
> Path path = resolveRelativePath(relPath).getNormalizedPath();
> return itemMgr.nodeExists(path);
> However, the repository doesn't even start up with that. Aparently the code relies on
the null check for id as well.
> Anyone have a better solution?

--
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

        

Mime
View raw message