5 ms·
Basically this, yeah. You can add or take down backends without having to keep web server config in sync and reload it. (Though config reloads are pretty light
by mholt 5y ago
Basically this, yeah. You can add or take down backends without having to keep web server config in sync and reload it. (Though config reloads are pretty light anyways.)
- paulgb 5y agoDoes it have implications for long-lived connections like SSE and websockets? It seems like restarts would have been disruptive to those but now might not be?
- mholt 5y agoPossibly; the long-lived connections eventually have to end when reloads (note: restarts and reloads are different) happen, to free up resources -- otherwise they leak. (The grace period is configurable and can even be disabled.)
- eliaspro 5y agoThis bit us in a recent project where we have very long ongoing downloads, where even a very high grace period wouldn't really help. I wonder whether it's technically generally feasible (possibly depends on net/http2's capabilities) to handover the connection from the old to the new server instance, comparable to what systemd does in terms of FD passing for socket-activated services.
- francislavoie 5y agoThe problem is that existing connections are inside of async functions (goroutines) that have references to the old config. AFAIK, there's no way in Go's stdlib to kill those goroutines while keeping the connection and handing it to another fresh goroutine. To be clear, the new config is running at the same time as the old is still tearing down; all new connections get handled by the new config. Listeners are shared and transferred between servers. We're all ears, though, if someone with deep knowledge of Go's internals can point us in the right direction.