jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3368) CachingHierarchyManager: inconsistent state after transient changes on root node
Date Wed, 18 Jul 2012 13:26:34 GMT

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

Stefan Guggisberg commented on JCR-3368:
----------------------------------------

> It seems that the special handling of the root node has nothing to do with this issue.


i cannot confirm this. AFAIU this issue only occurs when removing a direct child of the root
node.
CachingHierarchyManager (CHM) keeps a reference on the root node's item state which seems
to become stale under certain cirumstances. 

i tried your altered test case. it failed on 
   
    session.getNode("/foo/bar/qux"); 

but that was because your test case doesn't clean up the test data. there were /foo.../foo[n]
nodes from previous test runs. when cleaning the test data before/after each run the test

doesn't fail anymore. 
                
> 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