Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <22409133.62271273482411074.JavaMail.jira@thor>
Date: Mon, 10 May 2010 05:06:51 -0400 (EDT)
From: "Thomas Mueller (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2618) Almost all application server threads
 were waiting for ReaderLock or WriterLock
In-Reply-To: <24525438.177201272142310301.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.