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