[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14359271#comment-14359271
]
Leif Hedstrom commented on TS-3312:
-----------------------------------
Coup[le of things:
1) I'm pretty sure this turns this previously overridable configuration into a
non-overridable one? At least in this usage. That should be addressed.
2) I'm fairly certain, unless I'm missing some C++ voodoo, that you are now
leaking the leases. I.e. we ought to do
{code}
diff --git a/proxy/http/HttpSessionManager.cc b/proxy/http/HttpSessionManager.cc
index c650ab6..deea98c 100644
--- a/proxy/http/HttpSessionManager.cc
+++ b/proxy/http/HttpSessionManager.cc
@@ -128,6 +128,7 @@ ServerSessionPool::releaseSession(HttpServerSession* ss)
// Once there is an active transaction on this connection, inactivity
timeout will be
// overwritten to transaction_no_activity_timeout_out
ss->get_netvc()->set_inactivity_timeout(HRTIME_SECONDS(http_config_params->oride.keep_alive_no_activity_timeout_out));
+ HttpConfig::release(http_config_params);
ss->get_netvc()->set_active_timeout(ss->get_netvc()->get_active_timeout());
// put it in the pools.
m_ip_pool.insert(ss);
{code}
> 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_alive_timeout.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)
