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 > >
