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 <[email protected]> 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)
