jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-2618) Almost all application server threads were waiting for ReaderLock or WriterLock
Date Tue, 27 Apr 2010 07:33:36 GMT

     [ https://issues.apache.org/jira/browse/JCR-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Thomas Mueller resolved JCR-2618.

    Resolution: Cannot Reproduce

>From the stack trace, it doesn't look like a deadlock, it's just slow. Right? I don't
think this qualifies as a bug.

It's hard to say why it was slow. I guess the problem can't be reproduced or solved with the
information you provided. See: http://wiki.apache.org/jackrabbit/QuestionsAndAnswers#Reporting_Problems

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

View raw message