Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <20205115.177321272143030072.JavaMail.jira@thor>
Date: Sat, 24 Apr 2010 17:03:50 -0400 (EDT)
From: "Sergei (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (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 updated JCR-2618:
------------------------

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


  was:
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)


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