[ https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368159#comment-14368159 ]
Dzmitry Markovich commented on TS-3312: --------------------------------------- [~amc] If I set this timeout after server_session->attach_hostname it will be overwritten to transaction timeout once we call server_session->release() - setting this timeout after we call server_session->release() is also not a good idea because we will simply overwrite the value we just set (transaction inactivity timeout to keepalive timeout). Also in HttpSM we call release() method that releases the session for K-A reuse 5 times: 1 time in HttpSM::tunnel_handler_server 1 time in HttpSM::tunnel_handler_ua 2 times in HttpSM::do_http_server_open 1 time in HttpSM::release_server_session > KA timeout to origin does not seem to honor configurations > ---------------------------------------------------------- > > Key: TS-3312 > URL: https://issues.apache.org/jira/browse/TS-3312 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP > Reporter: Leif Hedstrom > Assignee: Brian Geffon > Fix For: 5.3.0 > > Attachments: keep_alive3.diff > > > Doing some basic testing, with the following settings: > {code} > CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120 > CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30 > {code} > I see ATS timing out the origin sessions after 30sec, with a > {code} > CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30 > {code} > What's also interesting, after I made a config change per Geffon's suggestion: > {code} > CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10 > {code} > I see the following in the diagnostic trace: > {code} > [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release > session] session placed into shared pool > [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] > [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], > reseting timeout to maintain minimum number of connections > [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] > [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], > reseting timeout to maintain minimum number of connections > [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] > [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS] > {code} > So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. > I first though it was the origin that closed the connection, but from what I > could tell, the timeout on the origin was set to 60s. -- This message was sent by Atlassian JIRA (v6.3.4#6332)