accept_no_activity_timeout seems obsolete but not removed.

[c-taylor]

Practical tests measuring the behaviour of accept_no_activity_timeout shows that is has no effect as documented.

https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/files/records.config.en.html#proxy-config-http-accept-no-activity-timeout

The timeout interval in seconds before Traffic Server closes a connection that has no activity.

---

A test such as:
time telnet localhost 80

Show that the parameter that affects this timeout is:
proxy.config.http.default_inactivity_timeout

There was a suggestion that the parameter proxy.config.http.transaction_no_activity_timeout_in may affect it also.
However in practical tests I cannot achieve this.

It doesn't look as though it's possible to remain in the state where this parameter is in effect within the state machine for more than an instant. I cannot begin to imagine the failure type that would cause this to occur, and be required.

There is an intent/architectural question about whether a client that has never submitted data should have a different timeout than one that has previously been active. Personally I would use this if available, being more aggressive to this client type.

At the very least: This parameter and references to it should be removed, and descriptions of default_inactivity_timeout updated to include this case. However, I'm not certain this makes sense as the default timeout, being the least specific, is often longer. The use case for accept_no_activity_timeout is typically one of the most agressive.

[c-taylor]

...write any data on the socket then txn_no_activity comes into play, even if that write is 'garbage'.

[shinrich]

Spent some time spelunking the code. There are HTTP/1.x and HTTP/2 scenarios. There is in fact a http2 version of the accept_no_activity_timeout setting. But let us first consider the HTTP/1 scenario.

The proxy.config.http.accept_no_activity_timeout value is used to set the inactivity timeout in HttpSM::attach_client_session() which is called from ProxyTransaction::new_transaction which is called from Http1ClientSession::new_transaction which is called from Http1ClientSession::release which is called from Http1ClientSession::start which is called from ProxySession::handler_api_return on the end of the TS_HTTP_SSN_START_HOOK.

attach_client_session sets the the inactivity timeout and then kicks off the TXN_START hook. Once the hook completes the HttpSM::state_read_client_request_header function is called which immediately resets the inactivity timeout to be the transaction_no_activity_timeout_in value. The state function is called via HttpSM::setup_client_read_request_header which feeds in the READ_READY in case this was a keep alive and there was already a request header in the read buffer.

So the accept_no_activity_timeout really only covers the TXN_START hook time, since there is no READ_READY waiting for the first read before kicking off the set up for reading the request header.

For the accept_no_activity_timeout to work as advertised (cover the gap between the connection start and the first request), this logic needs to be shoved down into the Http1ClientSession class like it is for Http2ClientSession and the http2 version of this setting.

The http2 version of the setting is set in Http2ClientSession:::new_connection and is reset to the proxy.config.http2.no_activity_timeout_in when the connection_preface is read.

[shinrich]

The logic that issued the READ_READY immediately was added in June 2015 by commit e9eeab6. As part of that change

index 1de4acc..f9962f0 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -545,8 +545,7 @@ HttpSM::setup_client_read_request_header()
   ua_entry->read_vio = ua_session->do_io_read(this, INT64_MAX, ua_buffer_reader->mbuf);
   // The header may already be in the buffer if this
   //  a request from a keep-alive connection
-  if (ua_buffer_reader->read_avail() > 0)
-    handleEvent(VC_EVENT_READ_READY, ua_entry->read_vio);
+  handleEvent(VC_EVENT_READ_READY, ua_entry->read_vio);
 }

If the READ_READY is sent conditionally (only if there is data in the buffer), then in theory, the accept_no_activity timeout should stick around until the first transaction byte arrives. I'll put up a PR for that for you to test @c-taylor

[shinrich]

Actually tried the telnet scenario locally. For that telnet with no data to even reach the traffic_server process you will need to set proxy.config.net.defer_accept to 0. Of course for the more common TLS scenario, this isn't an issue.

Once I turned off defer accept, the UnixNetVConnection::acceptEvent handler was setting the timeout to 0, and then nothing else happened until the proxy.config.net.default_inactivity_timeout triggered.

So it appears that my PR isn't going to help anything at least in the non-TLS case. The accept timeout needs to be applied earlier.

[shinrich]

Pushed another commit that fixes the issue by moving the application of the accept_no_activity_timeout to the ProtocolProbeSessionAccept class. This logic is triggered after the TLS handshake or the TCP handshake even if no additional data is ready and waiting. There was even a comment there suggesting this might be a good place to apply that timeout.

Also added a new autest to exercise. Lots of lovely shell to get the elapsed time of the client command, but I'm unclear how to inject the python to compute and test the elapsed time.