You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Michał Łowicki <ml...@gmail.com> on 2018/12/19 20:16:13 UTC
ACK status update before or after handler?
Hey!
By looking at mesos-go <https://github.com/mesos/mesos-go> I've found that
in example that ACK is done before handler is being called (here
<https://github.com/mesos/mesos-go/blob/master/api/v1/cmd/msh/msh.go#L185>).
Couldn't find similar way to do it after handler. I guess it depends on the
use case but what usually works better (if any)? In my understanding if ACK
is before handler then it may end up in situation where handler for e.g.
RUNNING and FAILED states interleave:
RUNNING -> ACK -> handler for RUNNING starts -> FINISHED -> ACK -> handler
for FINISHED starts -> handler for FINISHED ends -> handler for RUNNING
ends.
When ACK is always after handler then handler for RUNNING state will end
before handler for FINISHED even starts. Any problems with such approach?
--
BR,
Michał Łowicki
Re: ACK status update before or after handler?
Posted by Michał Łowicki <ml...@gmail.com>.
Thanks!
On Thu, Dec 20, 2018 at 6:58 PM James DeFelice <ja...@gmail.com>
wrote:
> ACK'ing can be performed completely async w/ respect to event handling,
> there's no need to perform an ACK on the same goroutine/thread as the event
> handling. Also, the example framework in mesos-go doesn't implement robust
> recovery in the face of failure.
>
> Generally speaking, you only want to ACK an update once your framework has
> durably recorded the fact that the update has been received from Mesos; for
> example, by updating some persistent state store. There's some additional
> discussion about ACKs in the Mesos docs:
> http://mesos.apache.org/documentation/latest/high-availability-framework-guide/#mesos-architecture
> .
>
>
> On Wed, Dec 19, 2018 at 3:16 PM Michał Łowicki <ml...@gmail.com> wrote:
>
>> Hey!
>>
>> By looking at mesos-go <https://github.com/mesos/mesos-go> I've found
>> that in example that ACK is done before handler is being called (here
>> <https://github.com/mesos/mesos-go/blob/master/api/v1/cmd/msh/msh.go#L185>).
>> Couldn't find similar way to do it after handler. I guess it depends on the
>> use case but what usually works better (if any)? In my understanding if ACK
>> is before handler then it may end up in situation where handler for e.g.
>> RUNNING and FAILED states interleave:
>>
>> RUNNING -> ACK -> handler for RUNNING starts -> FINISHED -> ACK ->
>> handler for FINISHED starts -> handler for FINISHED ends -> handler for
>> RUNNING ends.
>>
>> When ACK is always after handler then handler for RUNNING state will end
>> before handler for FINISHED even starts. Any problems with such approach?
>>
>> --
>> BR,
>> Michał Łowicki
>>
>
>
> --
> James DeFelice
> 585.241.9488 (voice)
> 650.649.6071 (fax)
>
--
BR,
Michał Łowicki
Re: ACK status update before or after handler?
Posted by James DeFelice <ja...@gmail.com>.
ACK'ing can be performed completely async w/ respect to event handling,
there's no need to perform an ACK on the same goroutine/thread as the event
handling. Also, the example framework in mesos-go doesn't implement robust
recovery in the face of failure.
Generally speaking, you only want to ACK an update once your framework has
durably recorded the fact that the update has been received from Mesos; for
example, by updating some persistent state store. There's some additional
discussion about ACKs in the Mesos docs:
http://mesos.apache.org/documentation/latest/high-availability-framework-guide/#mesos-architecture
.
On Wed, Dec 19, 2018 at 3:16 PM Michał Łowicki <ml...@gmail.com> wrote:
> Hey!
>
> By looking at mesos-go <https://github.com/mesos/mesos-go> I've found
> that in example that ACK is done before handler is being called (here
> <https://github.com/mesos/mesos-go/blob/master/api/v1/cmd/msh/msh.go#L185>).
> Couldn't find similar way to do it after handler. I guess it depends on the
> use case but what usually works better (if any)? In my understanding if ACK
> is before handler then it may end up in situation where handler for e.g.
> RUNNING and FAILED states interleave:
>
> RUNNING -> ACK -> handler for RUNNING starts -> FINISHED -> ACK -> handler
> for FINISHED starts -> handler for FINISHED ends -> handler for RUNNING
> ends.
>
> When ACK is always after handler then handler for RUNNING state will end
> before handler for FINISHED even starts. Any problems with such approach?
>
> --
> BR,
> Michał Łowicki
>
--
James DeFelice
585.241.9488 (voice)
650.649.6071 (fax)