[
https://issues.apache.org/jira/browse/SAMZA-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065758#comment-16065758
]
Navina Ramesh commented on SAMZA-1348:
--------------------------------------
bq. Note. Since we are using scheduler's thread to run stop(), we won't be able
to run scheduler.stop(). But that should be fine, since it is a daemon thread.
Iirc, I think you should be able to shutdown the scheduler thread from within a
scheduled task. But definitely double check :)
QQ: When you queue up a stop task in the debounce thread after canceling
pending tasks, are you also *not* accepting any more task submissions? I think
we may have to maintain a state for the scheduler/jobcoordinator to make sure
we don't get a `scheduleTask` request from other components before the stop
task is invoked. Not sure if there will be any serious consequences if we don't
do it. It will, however, make the ordering of shutdown of components (the
various tasks, zkclient etc) more deterministic.
> Run stop() in the StreamProcessor in the same thread as other events.
> ---------------------------------------------------------------------
>
> Key: SAMZA-1348
> URL: https://issues.apache.org/jira/browse/SAMZA-1348
> Project: Samza
> Issue Type: Bug
> Reporter: Boris Shkolnik
>
> stop() should be running in the same thread as other events. Since sometimes
> it is invoked form the container thread, it may end up running at the same
> time as another event from ZK.
> Even, if one of the first things stop() does is stopping the scheduler, an
> event still may be running. So the solution would be to call the stop () from
> JobCoordinator, using the same debouncing thread as every other event. It
> will do the following:
> * Cancel all the currently en-queued tasks. It still may have one task
> running.
> * Schedule itself (stop()) on the same debounce thread.
> Note. Since we are using scheduler's thread to run stop(), we won't be able
> to run scheduler.stop(). But that should be fine, since it is a daemon
> thread.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
