Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 1806D200C30 for ; Tue, 7 Mar 2017 18:17:43 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 169BD160B68; Tue, 7 Mar 2017 17:17:43 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3C30A160B65 for ; Tue, 7 Mar 2017 18:17:42 +0100 (CET) Received: (qmail 68050 invoked by uid 500); 7 Mar 2017 17:17:41 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 68040 invoked by uid 99); 7 Mar 2017 17:17:41 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Mar 2017 17:17:41 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id F00711A0423 for ; Tue, 7 Mar 2017 17:17:40 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.652] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id q1iuEDAe8906 for ; Tue, 7 Mar 2017 17:17:39 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id EE0315FC06 for ; Tue, 7 Mar 2017 17:17:38 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 5B807E0294 for ; Tue, 7 Mar 2017 17:17:38 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 0A8F824168 for ; Tue, 7 Mar 2017 17:17:38 +0000 (UTC) Date: Tue, 7 Mar 2017 17:17:38 +0000 (UTC) From: "Vinayak (JIRA)" To: dev@jackrabbit.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (JCR-2791) Potential deadlock in LockManagerImpl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 07 Mar 2017 17:17:43 -0000 [ https://issues.apache.org/jira/browse/JCR-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899792#comment-15899792 ] Vinayak commented on JCR-2791: ------------------------------ Hi All, Can you please let us know how this issue was resolved. We are also getting same issue in our environment > Potential deadlock in LockManagerImpl > ------------------------------------- > > Key: JCR-2791 > URL: https://issues.apache.org/jira/browse/JCR-2791 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core > Affects Versions: 2.0, 2.1, 2.1.1 > Reporter: Jukka Zitting > Priority: Minor > > I have a deadlock case that consists of the following *three* threads blocking each other: > Thread A - a writer that's waiting for a write lock on the SISM: > - waiting on <0x29283ca6> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) > - locked <0x29283ca6> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:485) > at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) > at org.apache.jackrabbit.core.state.DefaultISMLocking$WriteLockImpl.(DefaultISMLocking.java:76) > at org.apache.jackrabbit.core.state.DefaultISMLocking$WriteLockImpl.(DefaultISMLocking.java:70) > at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:64) > at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1471) > at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:112) > at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:555) > at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1110) > at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1140) > at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) > at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) > at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) > at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:328) > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1141) > Thread B - a reader that's waiting for a read lock on the SISM: > - waiting on <0x7d1d0717> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) > - locked <0x7d1d0717> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:485) > at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source) > at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.(DefaultISMLocking.java:102) > at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.(DefaultISMLocking.java:96) > at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:53) > at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1457) > at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:250) > at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:107) > at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:172) > at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:200) > at org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(HierarchyManagerImpl.java:152) > at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:395) > at org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:232) > at org.apache.jackrabbit.core.lock.LockManagerImpl.getPath(LockManagerImpl.java:856) > at org.apache.jackrabbit.core.lock.LockManagerImpl.getLockInfo(LockManagerImpl.java:547) > at org.apache.jackrabbit.core.lock.XALockManager.isLocked(XALockManager.java:158) > at org.apache.jackrabbit.core.lock.SessionLockManager.isLocked(SessionLockManager.java:108) > at org.apache.jackrabbit.core.NodeImpl.isLocked(NodeImpl.java:3325) > Thread C - a writer that's delivering synchronous observation events to a LockManagerImpl instance: > - waiting on <0x3fc267ca> (a org.apache.jackrabbit.core.state.LocalItemStateManager) > - locked <0x3fc267ca> (a org.apache.jackrabbit.core.state.LocalItemStateManager) > owned by Thread B > at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:167) > at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:200) > at org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:390) > at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:336) > at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:615) > at org.apache.jackrabbit.core.lock.LockManagerImpl.refresh(LockManagerImpl.java:1186) > at org.apache.jackrabbit.core.lock.LockManagerImpl.nodeAdded(LockManagerImpl.java:1217) > at org.apache.jackrabbit.core.lock.LockManagerImpl.onEvent(LockManagerImpl.java:1120) > at org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:246) > at org.apache.jackrabbit.core.observation.ObservationDispatcher.dispatchEvents(ObservationDispatcher.java:214) > at org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:475) > at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:765) > at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1140) > at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) > at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) > at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) > at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:328) > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1141) > The problem here is that thread C is trying to deliver synchronous observation events (i.e. it's still holding a downgraded SISM lock) to the LockManagerImpl instance of the session used in thread B. The event handling code in LockManagerImpl uses the session-local LocalItemStateManager instance, whose monitor has already been entered by thread B. Thread B is being blocked by thread A and the writer preference nature of the SISM lock, and thread A can't proceed until thread C has released the SISM lock it's currently holding. > The specific LocalItemStateManager synchronization block seen here has already been removed as a part of my JCR-2699 changes, so this specific deadlock can no longer occur with the latest trunk, but I'm still filing this issue at "Minor" priority as we should still review the above scenario for other potential deadlock issues. Ideally we'd either make the LockManagerImpl use normal instead of synchronous observation, or avoid ItemManager access in the LockManagerImpl event processing code. -- This message was sent by Atlassian JIRA (v6.3.15#6346)