[jira] [Commented] (SLING-3220) TimedEventSender put into a busy endless loop, after topology changes

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811163#comment-13811163 ] 

Carsten Ziegeler commented on SLING-3220:
-----------------------------------------

I think this is introducing a new problem - the idea of stopping the queue is to stop/suspend the queue thread until the topology is stable again. With the patch in place, new events coming in while the topology is not stable, these events are immediately processed.
Of course the endless loop is not correct either. So I think this needs to be fixed completeley different: when stopped, the thread should sleep until woken up again.

> TimedEventSender put into a busy endless loop, after topology changes
> ---------------------------------------------------------------------
>
>                 Key: SLING-3220
>                 URL: https://issues.apache.org/jira/browse/SLING-3220
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Event 3.3.0
>            Reporter: Marc Pfaff
>         Attachments: SLING-3220.patch
>
>
> There seem's to be an issue in the TimedEventSender that puts the related background thread into a busy endless loop. This has two effects:
> * Heavy CPU usage
> * Timed Jobs are never finished, if in the busy loop
> That's what I found out when debugging so far:
> * TimedEventSender starts a background thread that takes events from a blocking queue
> * If the event's topic is org/apache/sling/event/impl/jobs/STOPPED, the event is never processed and there is no new event taken from the queue, thus it's not properly waiting, but instead falls into the endless loop, as the event instance is never set to null
> * Events with the 'stop topic' are sent upon topology change event, handled by TimedEventSender itself, thus this only happens as soon as a new instance is joining the topology. 
> In order to reproduce:
> * one must have a second instance joining the same topology
> I will try to come up with a patch. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)