Hi Amaury, Thanks to you and Willy for going through it. A quick note on one point before your next discussion; I will come back on the rest.
On Thu, 2026-11-05 at 16:47 +0100, Amaury Denoyelle wrote: > It is probably not desirable to kill every idle connections, as this > could cause 503s for clients still connected to the older worker > process. Thus, a middleground approach would be to kill at most half of > the connections currently present on the server. Of course, this is > still limited to idle connections only. Note that > srv_migrate_conns_to_remove() already has a parameter to limit the > purged entries. Closing half leaves the new process with half of the dialer's connections, and for rhttp that is not enough. A busy reverse connection can only be used by the thread that owns it: only idle connections are taken over by other threads. So a dialer has to keep at least nbthread connections, or under load requests landing on a thread that holds none get an immediate 503 (SC--). With half of them, the new process is back in that situation, which is the outcome this is trying to avoid, moved from the old process to the new one. The other half also stays idle on the old process until it exits, since rhttp users need a long pool-purge-delay (a purged reverse connection cannot be re-established by haproxy). So the stranding is halved rather than removed. Doubling the dialer's connections would work around it, but it would deepen a dependency that is already easy to miss: the number of reverse connections a dialer opens has to track the gateway's thread count. What matters from the dialer's side is that the new process ends up with as many of its connections as possible, at least one per thread, and soon after the reload. I will leave how best to balance that against the clients still on the legacy worker to you and Willy. Cheers, Dustin
