[
https://issues.apache.org/jira/browse/MESOS-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14281551#comment-14281551
]
Robert Lacroix commented on MESOS-2198:
---------------------------------------
Yes, I agree. We should update mesos.proto though:
{code}
/**
* A framework generated ID to distinguish a task. The ID must remain
* unique while the task is active. However, a framework can reuse an
* ID _only_ if a previous task with the same ID has reached a
* terminal state (e.g., TASK_FINISHED, TASK_LOST, TASK_KILLED, etc.).
*/
{code}
suggests reusing task ids is perfectly fine.
> Scheduler#statusUpdate should not be called multiple times for the same
> status update
> -------------------------------------------------------------------------------------
>
> Key: MESOS-2198
> URL: https://issues.apache.org/jira/browse/MESOS-2198
> Project: Mesos
> Issue Type: Bug
> Components: framework
> Reporter: Robert Lacroix
>
> Currently Scheduler#statusUpdate can be called multiple times for the same
> status update, for example when the slave retransmits a status update because
> it's not acknowledged in time. Especially for terminal status updates this
> can lead to unexpected scheduler behavior when task id's are being reused.
> Consider this scenario:
> * Scheduler schedules task
> * Task fails, slave sends TASK_FAILED
> * Scheduler is busy and libmesos doesn't acknowledge update in time
> * Slave retransmits TASK_FAILED
> * Scheduler eventually receives first TASK_FAILED and reschedules task
> * Second TASK_FAILED triggers statusUpdate again and the scheduler can't
> determine if the TASK_FAILED belongs to the first or second run of the task.
> It would be a lot better if libmesos would dedupe status updates and only
> call Scheduler#statusUpdate once per status update it received. Retries with
> the same UUID shouldn't cause Scheduler#statusUpdate to be executed again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
