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