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