This patch adds another separate shutdown mechanism that only works for
HTTP/2. I think that we really ought to have a single, well-defined
graceful shutdown that works for all protocols.
In HTTP/1.1 it works like this:
- You (possibly dynamically) set
proxy.config.restart.active_client_threshold
- You run “traffic_ctl server restart —drain”
Then, once client connections have been drained to the threshold,
traffic_server restarts. Note that this assumes that you have some
additional orchestration that triggers header_rewrite to inject a
“Connection: close” header, and tell the GSLB to stop sending new
connections.
After this HTTP/2 change, there is a new graceful shutdown path
- You (at startup only) set proxy.config.stop.shutdown_timeout
- You send a signal to traffic_server
This flips a global variable to the “drain” state, then sleeps in
the signal handler until the timeout is reached. In HTTP/2 only, any new
connections will be accepted and then immediately closed.
To rationalize these disparate approaches, I suggest that we go back to
the traffic_ctl methodology, and enhance it so that it sends a message
to traffic_server that puts it into a known draining state. This should
be published in a metric and should be reversible so you can abort the
drain. The metric can be observed by HTTP/1.1 and HTTP/2 to take
appropriate action. We should also add a new setting
“proxy.config.restart.active_client_timeout” (or something like
that) to handle the maximum time to wait for traffic to drain.
I’m not sure whether it is a good idea to close connections in HTTP/2
while we are in draining state. If there is a desire for this, I would
like it to be configurable (defaulting to off).
On 8 May 2017, at 18:17, Masakazu Kitajo wrote:
Merged #1710.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/trafficserver/pull/1710#event-1073784726
