[ https://issues.apache.org/jira/browse/AURORA-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484533#comment-15484533 ]
Maxim Khutornenko commented on AURORA-1769: ------------------------------------------- My suggestion was targeting the restart issue where events should be suppressed regardless: you don't want to resend {{TaskStateChange}} events for all tasks every time a scheduler restarts. As for the general perf issue, blocking {{EventBus}} threads was one of the concerns raised in the original https://reviews.apache.org/r/47440/ RB. We concluded back then that using aggressive connection timeouts _was_ appropriate to mitigate possible event queue saturation. If you feel that is no longer the case, please follow up with an async proposal. You'll likely need something akin the [BatchWorker|https://reviews.apache.org/r/51759/] sending thread working off of its own queue. In any case, given this feature is optional and off by default I feel blocking the release until it's improved is not justified. > Enabling webhook is synchronous and could cause longer leader reelection cycle > ------------------------------------------------------------------------------ > > Key: AURORA-1769 > URL: https://issues.apache.org/jira/browse/AURORA-1769 > Project: Aurora > Issue Type: Bug > Reporter: Dmitriy Shirchenko > Assignee: Dmitriy Shirchenko > > We had an issue where on scheduler leader reelection EventBus was full of > TaskStateChange events and caused scheduler to not be able to post > DriverRegistered() message which caused Aurora scheduler to not register > within 1 minute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)