jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-2746) Sleep in possibly endless loop in ObservationDispatcher
Date Wed, 22 Sep 2010 12:46:35 GMT

     [ https://issues.apache.org/jira/browse/JCR-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jukka Zitting updated JCR-2746:

    Attachment: JCR-2746.patch

Could we come up with a solution that doesn't require the extra bits of state and responsibility
in SessionContext and the new public method in SessionImpl? Also, having the delay carried
over to the next session operation seems a bit troublesome to me. It would be better to keep
the extra delay within the scope of the currently executed operation.

How about the attached patch where I move the delay to the finally block of SessionState.perform()
and use just an extra ObservationDispatcher.isEventQueueOverloaded() predicate to carry the
required bit of state across the system?

> Sleep in possibly endless loop in 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
>         Attachments: JCR-2746.patch, TestObservationEndlessLoop.java
> 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