You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Anand Mazumdar (JIRA)" <ji...@apache.org> on 2016/07/13 15:54:20 UTC

[jira] [Updated] (MESOS-5262) slave::statusUpdate() should always ACK the status update sent by executor

     [ https://issues.apache.org/jira/browse/MESOS-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anand Mazumdar updated MESOS-5262:
----------------------------------
    Fix Version/s: 1.1.0

> slave::statusUpdate() should always ACK the status update sent by executor
> --------------------------------------------------------------------------
>
>                 Key: MESOS-5262
>                 URL: https://issues.apache.org/jira/browse/MESOS-5262
>             Project: Mesos
>          Issue Type: Improvement
>          Components: slave
>            Reporter: Qian Zhang
>              Labels: mesosphere
>             Fix For: 1.1.0
>
>
> In {{slave::statusUpdate()}}, there are several scenarios where agent ignores a status update sent by the executor and will not send an ACK to the executor, e.g.:
> When agent receives a {{ShutdownFrameworkMessage}} from master, {{slave::shutdownFramework()}} will be called. In this method, we will set the state of framework to {{TERMINATING}} and send a {{ShutdownExecutorMessage}} to executor. When executor receives that message, usually it will kill the tasks and send {{TASK_KILLED}} status update to agent. Agent will receive that message and handle it in {{slave::statusUpdate()}}, but according to the currently logic of {{slave::statusUpdate()}}, it will ignore the status update if the state of framework is {{TERMINATING}}, so agent will not send an ACK to the executor.
> Since executor may rely on the ACK (e.g., HTTP command executor relies on the ACK of a terminal status update to terminate itself), we should enhance it such that executor can always get an ACK for the status update sent by it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)