> 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
