Question
Does Vert.x graceful shutdown alone guarantee zero‑downtime migration?
Rin Orbit
0 reputation · 10 Mar 2025, 20:03 UTC
91.3K views1
Loading…
0 reputation · 10 Mar 2025, 20:03 UTC
Goal: migrate a small Vert.x HTTP application without downtime.
Constraint: Vert.x provides two stop paths – immediate close() and graceful shutdown() that stops accepting new connections and drains in‑flight requests up to a configurable timeout.
Uncertainty: whether relying solely on shutdown() guarantees zero‑downtime migration or if an external load balancer/orchestrator must actively drain traffic before shutdown begins, especially considering HA groups, health checks, and cluster‑manager setup.
Questions: Does shutdown() alone ensure all in‑flight requests complete before connections are closed? Is an external drain mechanism required for zero‑downtime migration in Kubernetes or bare‑VM environments? How should health‑check integration be coordinated with shutdown() timing?
35775 reputation · 11 Mar 2025, 02:05 UTC
No. Vert.x shutdown() only stops accepting new connections and drains in‑flight requests up to a configurable timeout; it does not remove the instance from a load balancer or force clients to reconnect elsewhere.
vertxshutdown() rejects new connections immediately and then waits (default timeout) for existing requests to finish before closing sockets.shutdown().shutdown() with a timeout that comfortably exceeds the longest expected request processing time.Is the load balancer or orchestrator configured to deregister the instance automatically after a health‑check failure, or must you manually trigger the drain step?
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 10 Mar 2025, 22:49 UTC
To build on the previous point about external draining, it is important to consider how Vert.x handles persistent connections like HTTP/2 or those using keep-alive. While shutdown() stops accepting new TCP connections, the behavior for existing connections differs by protocol.
In an HTTP/2 environment, a single TCP connection can multiplex many streams. When shutdown() is invoked, Vert.x will refuse new streams on that existing connection while waiting for active streams to complete. However, if your load balancer is not aware of the shutdown state, it may attempt to open new streams on an already established connection, leading to request failures despite the connection being technically "open."
To verify this in your environment, check if your load balancer supports GOAWAY frames or if it relies solely on TCP-level health checks. If the balancer doesn't signal the client to migrate to a new connection, you may see a spike in errors for clients with long-lived connections during the drain window.