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

["Ritwik Yadav (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949298#comment-13949298 ] 

Ritwik Yadav commented on MESOS-808:
------------------------------------

I found this interesting to implement. However, I would like to discuss some things. As of right now, when a request is made by the scheduler, the corresponding scheduler driver returns the status (of the driver). However, I could not understand the last paragraph in the issue description above. The idea of maintaining a queue of messages yet to be dispatched when the scheduler re-connects made sense to me. I cannot figure out how sending a future object as a result of sending a message would help. Maybe I am wrong, but doesn't the scheduler already know that from the status of the driver which is returned?

> 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: 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.2#6252)