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

Marco Massenzio commented on MESOS-3583:
----------------------------------------

Following from our conversation, I don't think we should consider doing this.
Adding session management introduces state that we will then need to manage in 
the even of failover; we already have failover management in Mesos and I don't 
really think that adding sessions would help any real-life use case.

We discussed the issue of badly implemented frameworks, but then that's a 
problem that's best solved via better documentation and education of the 
community.

> Introduce sessions in HTTP Scheduler API Subscribed Responses
> -------------------------------------------------------------
>
>                 Key: MESOS-3583
>                 URL: https://issues.apache.org/jira/browse/MESOS-3583
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Anand Mazumdar
>              Labels: mesosphere, tech-debt
>
> Currently, the HTTP Scheduler API has no concept of Sessions aka 
> {{SessionID}} or a {{TokenID}}. This is useful in some failure scenarios. As 
> of now, if a framework fails over and then subscribes again with the same 
> {{FrameworkID}} with the {{force}} option set. The Mesos master would 
> subscribe it.
> If the previous instance of the framework/scheduler tries to send a Call , 
> e.g. {{Call::KILL}} with the same previous {{FrameworkID}} set, it would be 
> still accepted by the master leading to erroneously killing a task.
> This is possible because we do not have a way currently of distinguishing 
> connections. It used to work in the previous driver implementation due to the 
> master also performing a {{UPID}} check to verify if they matched and only 
> then allowing the call.



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

Reply via email to