goagain does not work!

[rbucker]

Running the following httperf command... almost 4000 transactions are lost because it takes about a second to relaunch the app.

httperf --num-calls=4000 --port= 48879 --uri=/mock --num-conns=10

Looking closely at the code it's not possible to have a zero downtime.

(a) goagain shares open connection
(b) there is no state migration
(c) during the swap no new connections can be made and therefore potential transactions lost

/r

[rcrowley]

Apologies for such a late reply, @rbucker881. I think maybe there's some omission on my part at work here. goagain doesn't make any effort to pass connections you've accepted to the new process; it only ensures the listening socket is never dropped.

https://github.com/rcrowley/goagain/blob/master/cmd/goagain-example/goagain-example.go#L64-L71 is a little bit hand-wavey but requests that you gracefully stop the process that's being restarted. For an HTTP server that means responding to the last request in-flight and closing the connection (this is certainly complicated by HTTP pipelining if you're being so exotic). Does that clear up the confusion I caused?

[rbucker]

Thank you for clearing that up. Having your code to test and consider the devops requirements for a websocket environment has been valuable to me. In order to have a truly operational environment I'll need more than just a daemontools framework to restart or at least a smarter daemontools RUN.

[rcrowley]

I wish I could say so more authoritatively but systemd looks to be able to supervise this sort of zero-downtime restart in ways daemontools, Upstart, and the like cannot.