[jira] Resolved: (JCR-2438) Multiple threads are trying to acquire journal writing lock, but none of the threads are holding the lock

["Thomas Mueller (JIRA)" <ji...@apache.org>]

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

Thomas Mueller resolved JCR-2438.
---------------------------------

    Resolution: Not A Problem

So it seems the connection to the database was lost. Do you know why?
If this is really the case, reconnecting is the right thing to do, so this doesn't sound like a bug. 

Depending on the reason why the connection was lost, 
maybe the delay before trying to reconnect should be lower?


> 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$WriterLock@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/XASessionImpl@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.