You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Thomas Mueller (JIRA)" <ji...@apache.org> on 2010/09/21 12:02:34 UTC
[jira] Created: (JCR-2753) Deadlock in DefaultISMLocking
Deadlock in DefaultISMLocking
-----------------------------
Key: JCR-2753
URL: https://issues.apache.org/jira/browse/JCR-2753
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
There seems to be a bug in DefaultISMLocking which was detected as part of JCR-2746.
1) The main thread gets a read lock.
2) The ObservationManager thread tries to lock for writing, which is blocked because there is still a read lock.
3) Then the main thread tries to get a second read lock, which is blocked because there is a waiting write lock.
The bug was introduced as part of JCR-2089 (Use java.util.concurrent), revisions 995411 and 995412. I think the safe solution is to revert those to commits, and add a test case. If the DefaultISMLocking is changed later on, more test cases are required. An efficient solution is relatively complicated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2753) Deadlock in DefaultISMLocking
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912985#action_12912985 ]
Marcel Reutegger commented on JCR-2753:
---------------------------------------
Can you please move the test to AbstractISMLockingTest in package o.a.j.core.state? the package o.a.j.core.lock is rather related to the JCR locking fuctionality and not internal jackrabbit locking.
> Deadlock in DefaultISMLocking
> -----------------------------
>
> Key: JCR-2753
> URL: https://issues.apache.org/jira/browse/JCR-2753
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.2.0
>
>
> There seems to be a bug in DefaultISMLocking which was detected as part of JCR-2746.
> 1) The main thread gets a read lock.
> 2) The ObservationManager thread tries to lock for writing, which is blocked because there is still a read lock.
> 3) Then the main thread tries to get a second read lock, which is blocked because there is a waiting write lock.
> The bug was introduced as part of JCR-2089 (Use java.util.concurrent), revisions 995411 and 995412. I think the safe solution is to revert those to commits, and add a test case. If the DefaultISMLocking is changed later on, more test cases are required. An efficient solution is relatively complicated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2753) Deadlock in DefaultISMLocking
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914525#action_12914525 ]
Jukka Zitting commented on JCR-2753:
------------------------------------
I restored the earlier revisions 995411 and 995412, applied the proposed patch, documented the reentrancy requirements in the ISMLocking javadocs, and modified the DefaultISMLockingDeadlockTest class accordingly in revision 1000947.
> Deadlock in DefaultISMLocking
> -----------------------------
>
> Key: JCR-2753
> URL: https://issues.apache.org/jira/browse/JCR-2753
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.2.0
>
> Attachments: JCR-2753.patch
>
>
> There seems to be a bug in DefaultISMLocking which was detected as part of JCR-2746.
> 1) The main thread gets a read lock.
> 2) The ObservationManager thread tries to lock for writing, which is blocked because there is still a read lock.
> 3) Then the main thread tries to get a second read lock, which is blocked because there is a waiting write lock.
> The bug was introduced as part of JCR-2089 (Use java.util.concurrent), revisions 995411 and 995412. I think the safe solution is to revert those to commits, and add a test case. If the DefaultISMLocking is changed later on, more test cases are required. An efficient solution is relatively complicated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2753) Deadlock in DefaultISMLocking
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller resolved JCR-2753.
---------------------------------
Fix Version/s: 2.2.0
Resolution: Fixed
Reverted the changes made by revision 995411 and revision 995412, and added a test case.
> Deadlock in DefaultISMLocking
> -----------------------------
>
> Key: JCR-2753
> URL: https://issues.apache.org/jira/browse/JCR-2753
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.2.0
>
>
> There seems to be a bug in DefaultISMLocking which was detected as part of JCR-2746.
> 1) The main thread gets a read lock.
> 2) The ObservationManager thread tries to lock for writing, which is blocked because there is still a read lock.
> 3) Then the main thread tries to get a second read lock, which is blocked because there is a waiting write lock.
> The bug was introduced as part of JCR-2089 (Use java.util.concurrent), revisions 995411 and 995412. I think the safe solution is to revert those to commits, and add a test case. If the DefaultISMLocking is changed later on, more test cases are required. An efficient solution is relatively complicated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2753) Deadlock in DefaultISMLocking
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913484#action_12913484 ]
Jukka Zitting commented on JCR-2753:
------------------------------------
Where's the case where a holder of a read lock reacquires the readlock? If we can't refactor that situation away, it should be easy enough to maintain a set of thread ids of all current readers so they can reenter the lock even when there's a writer waiting.
> Deadlock in DefaultISMLocking
> -----------------------------
>
> Key: JCR-2753
> URL: https://issues.apache.org/jira/browse/JCR-2753
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.2.0
>
>
> There seems to be a bug in DefaultISMLocking which was detected as part of JCR-2746.
> 1) The main thread gets a read lock.
> 2) The ObservationManager thread tries to lock for writing, which is blocked because there is still a read lock.
> 3) Then the main thread tries to get a second read lock, which is blocked because there is a waiting write lock.
> The bug was introduced as part of JCR-2089 (Use java.util.concurrent), revisions 995411 and 995412. I think the safe solution is to revert those to commits, and add a test case. If the DefaultISMLocking is changed later on, more test cases are required. An efficient solution is relatively complicated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2753) Deadlock in DefaultISMLocking
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-2753:
-------------------------------
Attachment: JCR-2753.patch
We discussed this with Thomas, and it turns out that synchronous observation listeners do need to reacquire ISM read locks after the SISM.Update.end() has downgraded the write lock it was holding. One way to solve this problem without having to maintain a set of current holders of the read lock is to simply remove the writer preference in the locking strategy, i.e. allow readers to acquire the lock even when there are pending writers waiting for the lock. Another solution, implemented in the attached patch (against the "new" DefaultISMLocking implementation of revision 99541), is to retain the writer thread identifier in a downgraded lock, so a downgraded write lock would still allow related threads to reacquire the lock even when there are other writers waiting.
> Deadlock in DefaultISMLocking
> -----------------------------
>
> Key: JCR-2753
> URL: https://issues.apache.org/jira/browse/JCR-2753
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.2.0
>
> Attachments: JCR-2753.patch
>
>
> There seems to be a bug in DefaultISMLocking which was detected as part of JCR-2746.
> 1) The main thread gets a read lock.
> 2) The ObservationManager thread tries to lock for writing, which is blocked because there is still a read lock.
> 3) Then the main thread tries to get a second read lock, which is blocked because there is a waiting write lock.
> The bug was introduced as part of JCR-2089 (Use java.util.concurrent), revisions 995411 and 995412. I think the safe solution is to revert those to commits, and add a test case. If the DefaultISMLocking is changed later on, more test cases are required. An efficient solution is relatively complicated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.