[ 
https://issues.apache.org/jira/browse/JCR-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912864#action_12912864
 ] 

Thomas Mueller commented on JCR-2746:
-------------------------------------

The bug in DefaultISMLocking was introduces with JCR-2089 (Use 
java.util.concurrent), revisions 995411 and 995412. I think the safe solution 
is to revert those to commits. Test case:

public void test() throws InterruptedException {
    final ISMLocking lock = new DefaultISMLocking();
    ReadLock r1 = lock.acquireReadLock(null);
    final InterruptedException[] ex = new InterruptedException[1];
    Thread thread = new Thread() {
        public void run() {
            try {
                lock.acquireWriteLock(null).release();
            } catch (InterruptedException e) {
                ex[0] = e;
            }
        }
    };
    thread.start();
    Thread.sleep(100);
    lock.acquireReadLock(null).release();
    r1.release();
    thread.join();
    if (ex[0] != null) {
        throw ex[0];
    }
}

This will result in a deadlock with the current DefaultISMLocking, but not with 
the old.


> Deadlock caused by ObservationDispatcher 
> -----------------------------------------
>
>                 Key: JCR-2746
>                 URL: https://issues.apache.org/jira/browse/JCR-2746
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, observation
>    Affects Versions: 2.0.0, 2.1.0, 2.1.1
>            Reporter: Jukka Zitting
>            Assignee: Thomas Mueller
>             Fix For: 2.2.0
>
>
> The rate-limitation code we added in JCR-2402 to prevent the observation 
> queue from growing too large was a good idea, but the current implementation 
> is a bit troublesome since it blocks the thread while it still holds the 
> journal lock, the SISM reader lock, and the SessionState lock. This can cause 
> a deadlock under heavy workloads if any of the observation listeners attempts 
> to reuse the session (not recommended/supported, but can still happen) or 
> write to the repository (quite likely).
> To solve this problem we should move the rate-limiter code to outside the 
> scope of any internal locks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to