[JCR-3991] Document partially not accessible

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Cannot Reproduce
• Affects Version/s: 2.8
• Component/s: jackrabbit-core
• Labels: help
• Environment: websphere server v7.0. Java 1.7
• Assignee: Unassigned
• Reporter: Grosperrin
• Created: 08/Jul/16 09:30
• Updated: 28/Aug/20 10:51
• Resolved: 04/May/20 13:57

Description

Hello,

I'm working on a system that store files into a JCR repository.

The data are accessible in a web page.
But sometimes when we try to access a file content (length in particular), an error linked to the chachinghierarchymanager occurs.

This unaccessibility occurs after the update of an existing document (but not everytime and mainly xlsx files). A restart of the server solve the issue.

I checked the following issue, but it didn't solved my problem : https://issues.apache.org/jira/browse/JCR-3368

public class DoctoDisplay {

private DoctoDisplayType type; //(file or folder)
private String name;
private Date modificationDate;
private Long fileSize;
private String docHref;
}

DoctoDisplay doctoDisplay = new DoctoDisplay();
if (type == doctoDisplayType.FILE)

{ doctoDisplay.setFileSize(inNode.getProperty("jcr:content/jcr:data").getLength())}

The logs of the error are below.

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)

To avoid the issue we are catching it and we don't display the length of the document, but we need to solve this.

Does anyone knows the root-cause of this issue ?
Is there an another way to access the length when the way I describe is not working ?
Would it be problem to destroy and then completelly recreate the tree when the problem occurs to reset it ?

Thank you in advance for your help.