[
https://issues.apache.org/jira/browse/JCR-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912473#action_12912473
]
Thomas Mueller commented on JCR-2746:
-------------------------------------
Thread.sleep can't be the root cause of a new deadlock. (Thread.sleep was added
in JCR-2402, but no additional synchronization or locking was introduced). But
Thread.sleep can *trigger* a deadlock that normally doesn't show up. So it it's
really a deadlock, it could also occur even without JCR-2402 (but less likely).
JCR-2402 calls Thread.sleep in a loop. If I replace the loop with an "if" then
I can reproduce some kind of deadlock. Currently it looks more like a bug in
DefaultISMLocking however... I'm analyzing it.
> 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.
