[
https://issues.apache.org/jira/browse/JCR-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912477#action_12912477
]
Thomas Mueller commented on JCR-2746:
-------------------------------------
There seems to be a bug in DefaultISMLocking:
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.
It looks like JCR-2402 is triggering this (so far hidden / undetected?) problem.
> 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.
