Hi Jeremy,

 

Thank you.  I’m sure the team has one from a previous test, and if not I’ll produce another and provide it here.

 

Thanks

 

Nick

 

 

From: Jeremy Payne <jp557198@gmail.com>
Reply-To: "users@trafficserver.apache.org" <users@trafficserver.apache.org>
Date: Wednesday, June 24, 2020 at 5:47 PM
To: "users@trafficserver.apache.org" <users@trafficserver.apache.org>
Subject: Re: Trying to understand no-activity timeouts
Resent-From: <Nick.Dunkin@ccur.com>

 

do you have a packet trace between child and parent during this 20s ttfb ?

 

ill retest, but in 7.x 'proxy.config.http.parent_proxy.connect_attempts_timeout' usually applies to both connection setup and ttfb.

 

 

 

On Wed, Jun 24, 2020 at 3:54 PM Nick Dunkin <Nick.Dunkin@vecima.com> wrote:

Hi Jeremy,

 

We are currently on 7.1.4

 

This issue seems to only occur when the Origin server does nothing other than accept the connection.  We mocked up an Origin server and experimented with “trickling the data” versus “waiting before sending the first byte” and the latter seems to be where we can’t get the timeout behavior we desire.

 

Many thanks

 

Nick

 

From: Jeremy Payne <jp557198@gmail.com>
Reply-To: "users@trafficserver.apache.org" <users@trafficserver.apache.org>
Date: Wednesday, June 24, 2020 at 3:57 PM
To: "users@trafficserver.apache.org" <users@trafficserver.apache.org>
Subject: Re: Trying to understand no-activity timeouts
Resent-From: <Nick.Dunkin@ccur.com>

 

yes.. what version of ATS are you using ?

 

 

On Wed, Jun 24, 2020 at 1:32 PM Nick Dunkin <Nick.Dunkin@vecima.com> wrote:

Hi Jeremy,

 

Thanks for the reply.

 

We did try that, but it did not behave as we expected, we still experienced a long response.  Have you used this parameter with parent routing with predictable results?

 

Cheers

 

Nick

 

From: Jeremy Payne <jp557198@gmail.com>
Reply-To: "users@trafficserver.apache.org" <users@trafficserver.apache.org>
Date: Wednesday, June 24, 2020 at 8:16 AM
To: "users@trafficserver.apache.org" <users@trafficserver.apache.org>
Subject: Re: Trying to understand no-activity timeouts

 

 

try setting this parameter.

 

proxy.config.http.parent_proxy.connect_attempts_timeout

 

 

On Tue, Jun 23, 2020 at 12:33 PM Nick Dunkin <Nick.Dunkin@vecima.com> wrote:

Hi,

 

We are still dealing with a particular kind of no-activity time out issue.

 

We are dealing with an Origin that will occasionally take 20 seconds to return a HTTP 500 (annoying, right).  We took a tcpdump and captured this occurring.  In the trace we can see the /GET and the ACK, and then a full 20 seconds (approx) before the HTTP 500 comes back.  Please see the below picture.

 

A screenshot of a cell phone

Description automatically generated

 

To be clear, apart from accepting the connection, the Origin Server sends NOTHING over the connection during the 20 seconds.

 

Without Parent Routing

 

This looks very much like something the Origin side “no-activity” timeouts should cater for, so we set both of the following (for good measure) to 2 seconds, but we still see exactly the same thing occurring.

 

CONFIG proxy.config.http.transaction_active_timeout_out INT 2
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 2

 

We managed to resolve this particular issue by using adding the following configuration, which is a “timeout to first byte”.  Is this the correct configuration solution for dealing with this issue?

 

CONFIG proxy.config.http.connect_attempts_timeout INT 2

 

This all seems to make sense based on the available documentation.  So far so good.

 

With Parent Routing

 

However, when we enable parent routing, and put the same single Origin Server in parent.config, we DO NOT see the “timeout to first byte” being applied.  What are we missing about these timeouts and how they interact with parent routing?

 

This all seems to hinge on the fact that the Origin server does not send a single byte for multiple seconds.    We see more predictable behavior if the Origin Server serves any data before the 20 seconds hang.

 

Very grateful for any insight.

 

Regards,

 

Nick Dunkin