[
https://issues.apache.org/jira/browse/JCR-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794775#action_12794775
]
Andrey Adamovich commented on JCR-2438:
---------------------------------------
Default sleeping time is 10 seconds, but because before going to sleep thread
is acquiring the journal lock, it blocks all other threads from doing update
operations for 10 seconds despite of the node they are updating.
> Multiple threads are trying to acquire journal writing lock, but none of the
> threads are holding the lock
> ---------------------------------------------------------------------------------------------------------
>
> Key: JCR-2438
> URL: https://issues.apache.org/jira/browse/JCR-2438
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 1.5.5
> Environment: R27.5.0-110_o-99226-1.5.0_14-20080528-1505-linux-x86_64
> weblogic 9.2
> Reporter: Andrey Adamovich
> Priority: Critical
> Attachments: jr_dump.txt
>
>
> Multiple threads that are saving content on one of the cluster nodes are
> hanging in attempt to get a lock to AbstractJournal:
> "[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default
> (self-tuning)'" id=14 idx=0x90 tid=30315 prio=1 alive, in native, waiting,
> daemon
> -- Waiting for notification on:
> EDU/oswego/cs/dl/util/concurrent/writerpreferencereadwritelock$writerl...@0x2b8cd608e770[fat
> lock]
> at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native
> Method)
> at java/lang/Object.wait(J)V(Native Method)
> at java/lang/Object.wait(Object.java:474)
> at
> EDU/oswego/cs/dl/util/concurrent/WriterPreferenceReadWriteLock$WriterLock.acquire()V(Unknown
> Source)
> at
> org/apache/jackrabbit/core/journal/AbstractJournal.lockAndSync(AbstractJournal.java:250)
> at
> org/apache/jackrabbit/core/journal/DefaultRecordProducer.append(DefaultRecordProducer.java:51)
> at
> org/apache/jackrabbit/core/cluster/ClusterNode$WorkspaceUpdateChannel.updateCreated(ClusterNode.java:586)
> at
> org/apache/jackrabbit/core/state/SharedItemStateManager$Update.begin(SharedItemStateManager.java:549)
> at
> org/apache/jackrabbit/core/state/SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1062)
> at
> org/apache/jackrabbit/core/state/SharedItemStateManager.update(SharedItemStateManager.java:1092)
> at
> org/apache/jackrabbit/core/state/LocalItemStateManager.update(LocalItemStateManager.java:337)
> at
> org/apache/jackrabbit/core/state/XAItemStateManager.update(XAItemStateManager.java:347)
> at
> org/apache/jackrabbit/core/state/LocalItemStateManager.update(LocalItemStateManager.java:312)
> at
> org/apache/jackrabbit/core/state/SessionItemStateManager.update(SessionItemStateManager.java:313)
> at org/apache/jackrabbit/core/ItemImpl.save(ItemImpl.java:1103)
> ^-- Holding lock:
> org/apache/jackrabbit/core/xasessioni...@0x2b8cf5d40d38[thin lock]
> at org/apache/jackrabbit/core/SessionImpl.save(SessionImpl.java:858)
> No thread is holding that lock. Thread dump is attached to the issue.
> This issues seems to be similar to JCR-1846.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
