I have run into some issues before where if you have permissions errors (lets say on SSL certs) then traffic_line will load no certs, and swap your nicely loaded ones for a big empty list. So, be careful with the traffic_line -x. Although it is "atomic" there are varying levels of sanity testing before the switch (remap is probably the best).
On Tue, Apr 28, 2015 at 8:10 AM, Leif Hedstrom <[email protected]> wrote: > It would get unresponsive if there are no task threads configured. > > -- Leif > > > > On Apr 28, 2015, at 7:28 AM, Alan Carroll <[email protected]> > wrote: > > One thing to note is the new remap configuration is loaded, or it is not. > The change over is atomic (for new transactions - already existing > transactions continue with the old remap configuration). I have to agree > with James that I've never heard of ATS becoming unresponsive during a > configuration reload - depending on the configuration it may take a minute > or two to load the new configuration, but ATS should continue to operate on > the old configuration until then. If it's not, that's a bug that needs to > be fixed. > > > > On Monday, April 27, 2015 6:27 PM, James Peach <[email protected]> > wrote: > > > > > On Apr 27, 2015, at 3:53 PM, Pushkar Sachdeva <[email protected]> > wrote: > > > > Hi ATS community, > > > > This is Pushkar from company Yahoo!. We have a use-case where we want to > avoid ATS restarts on new ATS remap rules deployment. For that we plan to > use 'sudo traffic_line -x' command to reload the ATS config instead of > doing a ATS restart. The problem is that after the reload we want to test > the new rules by running some sanity tests (http/https requests) against > ATS to make sure it is responding as expected. I have heard that after the > 'traffic_line -x' command the traffic server can become unresponsive for > sometime (0-2 mins) before it completely loads the config again and is > ready to serve the new requests. > > AFAIK this is not correct. > > > This undeterministic behavior is a problem as we don't know when ATS is > ready to take up new requests and therefore don't know when should we run > the sanity tests. Any timed out sanity tests requests are treated as > failures. Also we cannot have large timeout values for the tests. Is there > any deterministic way to find out when ATS is ready to take up new requests > after 'traffic_line -x' command is executed (any stat/config I can look for > to confirm that the new config load has completed)? > > There’s a number of relevant metrics: > > proxy.node.config.reconfigure_time - timestamp of the last reconfiguration > proxy.node.config.reconfigure_required - whether a reconfiguration is > required > proxy.node.config.restart_required.* - whether one of the daemon processes > needs to be restarted > > > > In the worst case we can probably put a sleep for 1-2 mins before we run > the sanity tests but was wondering if there is a better way to handle this ? > > > > Regards, > > Pushkar > > >
