Thanks! On Thu, Dec 20, 2018 at 6:58 PM James DeFelice <james.defel...@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 <mlowi...@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
