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)