Before making this statement, think of how the following states can really be non-disruptively handled:
1) requests in transit to nginx (in-flight)
2) TCP handshakes just completed (not yet accepted)
3) TCP handshakes in progress (clients will retry if server doesn't RST)
Nginx cannot know if requests are in transit nor it can handle just established TCP conns. It also does not drain
the backlog queue in the old processes. It simply tears down
estimated 'idle' connections.
Try a test with heavy load and you will see. More network latency more errors...
That's exactly why Nginx Plus offers dynamic upstream modification features as opposed to relying on reload.
1) requests in transit to nginx (in-flight) 2) TCP handshakes just completed (not yet accepted) 3) TCP handshakes in progress (clients will retry if server doesn't RST)
Nginx cannot know if requests are in transit nor it can handle just established TCP conns. It also does not drain the backlog queue in the old processes. It simply tears down estimated 'idle' connections.
Try a test with heavy load and you will see. More network latency more errors...
That's exactly why Nginx Plus offers dynamic upstream modification features as opposed to relying on reload.