jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2753) Deadlock in DefaultISMLocking
Date Wed, 22 Sep 2010 10:15:33 GMT

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


Mime
View raw message