Thank you all for the valuable insights. I will keep those in mind.
Regards,Pushkar
On Tuesday, April 28, 2015 9:00 AM, Thomas Jackson
<[email protected]> wrote:
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
