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