You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Dominic Hamon (JIRA)" <ji...@apache.org> on 2015/02/09 20:38:36 UTC

[jira] [Resolved] (MESOS-808) The scheduler driver should queue messages when disconnected or return delivery status.

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

Dominic Hamon resolved MESOS-808.
---------------------------------
    Resolution: Won't Fix

No longer an issue under the HTTP API.

> The scheduler driver should queue messages when disconnected or return delivery status.
> ---------------------------------------------------------------------------------------
>
>                 Key: MESOS-808
>                 URL: https://issues.apache.org/jira/browse/MESOS-808
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Benjamin Mahler
>              Labels: twitter, v1_api
>
> Currently when schedulers try to take an action while the driver is disconnected (i.e. a call to SchedulerDriver::disconnected has occurred), the driver will drop the request.
> In the case of launching a task, we'll reply with TASK_LOST directly in the driver. However, with things like killTask, we simply drop the kill task request.
> This behavior seems a little unfriendly for schedulers, as they need to be concerned about queueing any operations until Scheduler::connected is called. We should consider queuing in the driver instead.
> The implementation here can consist of a queue<Message> holding the messages that were constructed while !connected. Once we re-connect, we simply run through this queue sending all messages.
> However, without state in the driver, schedulers will have to live with the possibility of dropped messages anyway (i.e. if they fail while disconnected, any messages will be lost).
> Therefore, an alternative here is possible when we add a v1 API. If we return a Future or other form of status we can indicate whether the message was sent. This is definitely simpler and more reliable than queueing.



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