[
https://issues.apache.org/jira/browse/JCR-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912917#action_12912917
]
Thomas Mueller commented on JCR-2746:
-------------------------------------
The deadlock in DefaultISMLocking is now tracked in JCR-2753.
Even if this is fixed, there is a problem with the ObservationDispatcher: the
loop to wait for the observation queue to shrink may be endless, because locks
are held by the current thread. It doesn't looks like there is an easy
solution, except for only waiting once (slowing down the main thread) instead
of waiting until the queue is shorter. In most cases, this will solve the
original problem (events are generated faster than processed), but it can't
result in an endless loop, even if the observation listener tries to read from
or write to the repository. Another option is to never wait / sleep, only to
log a warning.
> Deadlock triggered 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.
