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

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

i've verified that it's a CachingHierarchyManager (CHM) issue.
the issue occurs because CHM tries to resolve the path based 
on stale cached state of the root node. pathCache/idCache 
don't seem to be correctly updated upon transient changes 
of the root node.

the test succeeds if the change does not affect the root node. 
this can e.g. be verified by applying the following change to the 
test:

-        session.getNode("/foo").remove();
+       session.getNode("/foo/bar").remove();

we should IMO try to fix the root cause (CachingHierarchyManager) 
instead of implementing workarounds for mere symptoms.


  
                
> Node#hasNode fails with RepositoryException because intermediate state cannot 
> be retrieved when it should just return false
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 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

        

Reply via email to