jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2746) Deadlock triggered by ObservationDispatcher
Date Tue, 21 Sep 2010 10:08:33 GMT

    [ 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.

View raw message