We'd also like a bit more fine grained control in the process -- we frequently want to perform maintenance on a server (upgrading ATS; upgrading the OS; performing hardware changes, etc) after draining but before restarting ATS. I suppose this would mean allowing the --drain option to apply to traffic_Ctl server stop.
miles On Mon, May 8, 2017 at 8:19 PM, James Peach <jpe...@apache.org> wrote: > 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 > > >
