Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <4437792.5121273133689368.JavaMail.jira@thor>
Date: Thu, 6 May 2010 04:14:49 -0400 (EDT)
From: "Sergei (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Reopened: (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:all-tabpanel ]

Sergei reopened JCR-2618:
-------------------------


Hi skilled!

Please have a look on this issue once again.


If the same issue was resolved before please add link to the root bug or patch fixed it.

I have looked through your resource and found the next issues:

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