[
https://issues.apache.org/jira/browse/MESOS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14973265#comment-14973265
]
Benjamin Mahler commented on MESOS-3583:
----------------------------------------
The motivation for this is to maintain parity with the existing driver concept
of a session (based on UPID uniqueness, see the ticket description). This
doesn't get persisted during failover: the lifetime of a session is tied to the
lifetime of a SUBSCRIBE connection against the master. Even properly
implemented frameworks can make mistakes without this (see the example in the
description).
> 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)
