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.

View raw message