jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grosperrin (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JCR-3991) Document partially not accessible
Date Wed, 03 Aug 2016 15:07:20 GMT

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

Grosperrin edited comment on JCR-3991 at 8/3/16 3:06 PM:
---------------------------------------------------------

It's one of the problem, we are not able to reproduce the issue...
I would say something like :

File file = new File("/mypath/mydocument.xlsx");     
FileInputStream is = new FileInputStream(file);   
Node node = session.getRootNode().addNode("foo");
session.save();
ValueFactory valueFactory = session.getValueFactory();               
Binary contentValue = valueFactory.createBinary(is);              
Node fileNode = node.addNode(fileName, "nt:file");   
session.save();
String size = node.getProperty("jcr:content/jcr:data").getLength();

Sorry for the delay of the reply.


was (Author: thibogrops):
It's one of the problem, we are not able to reproduce the issue...
I would say something like :

File file = new File("/mypath/mydocument.xlsx");     
FileInputStream is = new FileInputStream(file);   
Node node = session.getRootNode().addNode("foo");
session.save();
ValueFactory valueFactory = session.getValueFactory();               
Binary contentValue = valueFactory.createBinary(is);              
Node fileNode = node.addNode(fileName, "nt:file");   
session.save();
String size = node.getProperty("jcr:content/jcr:data").getLength();

> Document partially not accessible 
> ----------------------------------
>
>                 Key: JCR-3991
>                 URL: https://issues.apache.org/jira/browse/JCR-3991
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.8
>         Environment: websphere server v7.0. Java 1.7
>            Reporter: Grosperrin
>              Labels: help
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message