Reusing taskIds may work if you're guaranteed to never be running two
instances of the same taskId simultaneously, but I could imagine a
particularly dangerous scenario where a master and slave experience a
network partition, so the master declares the slave lost and therefore its
tasks lost, and then the framework scheduler launches a new task with the
same taskId. However, the task is still running on the original slave. When
the slave reregisters and claims it is running that taskId, or that that
taskId has completed, the Mesos master may have a difficult time
reconciling which instance of the task is on which node and in which
status, since it expects only one instance to exist at a time.
You may be better off using a fixed taskId prefix and appending an
incrementing instance/trial number so that each run gets a uniqueId. Also
note that taskIds only need to be unique within a single frameworkId, so
don't worry about conflicting with other frameworks.
TL;DR: I wouldn't recommend it.
On Fri, Jul 10, 2015 at 10:20 AM, Antonio Fernández <
antonio.fernan...@bq.com> wrote:
> Sounds risky. Every task should have its own unique id, collisions could
> happen and unexpected issues.
>
> I think it will be as hard to monitor that you can start again a task than
> get a mechanism to know it’s ID.
>
>
>
> On 10 Jul 2015, at 19:14, Jie Yu <yujie....@gmail.com> wrote:
>
> Re-using Task IDs is definitely not encouraged. As far as I know, many of
> the Mesos code assume Task ID is unique. So I probably won't risk that.
>
>
> On Fri, Jul 10, 2015 at 10:06 AM, Sargun Dhillon <sar...@sargun.me> wrote:
>
>> Is reusing Task IDs good behaviour? Let's say that I have some
>> singleton task - I'll call it a monitoring service. It's always going
>> to be the same process, doing the same thing, and there will only ever
>> be one around (per instance of a framework). Reading the protobuf doc,
>> I learned this:
>>
>>
>> /**
>> * 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.).
>> */
>> message TaskID {
>> required string value = 1;
>> }
>> ---
>> Which makes me think that it's reasonable to just give this task the
>> same taskID, and that every time I bring it from a terminal status to
>> running once more, I can reuse the same ID. This also gives me the
>> benefit of being able to more easily locate the task for a given
>> framework, and I'm able to exploit Mesos for some weak guarantees
>> saying there wont be multiple of these running (don't worry, they lock
>> in Zookeeper, and concurrent runs don't do anything, they just fail).
>>
>> Opinions?
>>
>
>
>
> Nos encantan los árboles. No me imprimas si no es necesario.
>
> Protección de Datos: Mundo Reader S.L. le informa de que los datos
> personales facilitados por Ud. y utilizados para el envío de esta
> comunicación serán objeto de tratamiento automatizado o no en nuestros
> ficheros, con la finalidad de gestionar la agenda de contactos de nuestra
> empresa y para el envío de comunicaciones profesionales por cualquier medio
> electrónico o no. Puede consultar en www.bq.com los detalles de nuestra
> Política de Privacidad y dónde ejercer el derecho de acceso, rectificación,
> cancelación y oposición.
>
> Confidencialidad: Este mensaje contiene material confidencial y está
> dirigido exclusivamente a su destinatario. Cualquier revisión, modificación
> o distribución por otras personas, así como su reenvío sin el
> consentimiento expreso está estrictamente prohibido. Si usted no es el
> destinatario del mensaje, por favor, comuníqueselo al emisor y borre todas
> las copias de forma inmediata. Confidentiality: This e-mail contains
> material that is confidential for de sole use of de intended recipient. Any
> review, reliance or distribution by others or forwarding without express
> permission is strictly prohibited. If you are not the intended recipient,
> please contact the sender and delete all copies.
>
