[
https://issues.apache.org/jira/browse/JCR-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865709#action_12865709
]
Thomas Mueller commented on JCR-2618:
-------------------------------------
> ItemNotFoundException: failed to build path of ...
A possible reason for this problem is concurrent use of the same session:
https://issues.apache.org/jira/browse/JCR-2456
In most cases such problems can be fixed using the 'consistency check /
consistency fix' feature of the persistence manager. See also
http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.html
This issue doesn't qualify as a bug. Please use the user list for questions
instead of re-opening this bug or creating a new bug.
> Almost all application server threads were waiting for ReaderLock or
> WriterLock
> --------------------------------------------------------------------------------
>
> Key: JCR-2618
> URL: https://issues.apache.org/jira/browse/JCR-2618
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 1.5.0, 1.5.2, 1.5.7
> Environment: Sun OS, Oracle DB, SAP AS
> Reporter: Sergei
> Attachments: ClusterNodeBlockStackttrace.txt, LockStackTrace.txt
>
>
> Hello Community!
> We need to advice on the server failure cases which related to Jackrabbit
> Content repository functionality.
> Almost all application server threads were waiting for ReaderLock or
> WriterLock (please find attached LockStackTrace.txt). In addition to the
> Read-/WriteLock there was blocked thread related to Jackrabbit cluster nodes
> functionality (please find attached ClusterNodeBlockStackttrace.txt).
> We have clustered environment and using the version of the Jackrabbit library
> as follows:
> concurrent-1.3.4.jar
> derby-10.2.1.6.jar
> jackrabbit-1.5.2-src.jar
> jackrabbit-api-1.5.0.jar
> jackrabbit-core-1.5.2.jar
> jackrabbit-jca-1.5.2.jar
> jackrabbit-jcr-commons-1.5.2.jar
> jackrabbit-spi-1.5.0.jar
> jackrabbit-spi-commons-1.5.0.jar
> jackrabbit-text-extractors-1.5.0.jar
> jcr-1.0.jar
> lucene-core-2.3.2.jar
> The advice that we need:
> 1) What could cause appearance of a Lock which prevent getting
> Reader-/WriterLock ?
> 2) Can it be related to the blocked thread from
> ClusterNodeBlockStackttrace.txt ?(please see attachments)
> We found that an update of GLOBAL_REVISION table can take up to 30 min
> ("GLOBAL_REVISION" - internal table name in Jackrabbit).
> Is it possible that this issue is related to the Read-\WriteLocks?
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.