[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14365977#comment-14365977
]
Leif Hedstrom commented on TS-3312:
-----------------------------------
I wasn't thrilled about the release either, but I'll manage. However, I feel
strongly that we should use better names in these signatures. For example:
{code}
void releaseSession(HttpServerSession* ss, ink_hrtime inactivity_timeout_in =
0);
void HttpServerSession::release(ink_hrtime timeout_in);
{code}
If I understand correctly, these are the KA timeouts for the origin
connections, no? Then the names of these parameters should reflect that, at a
minimum they should be named _out, but even so, inactivity_timeout_out is very
confusing since we have another timeout for exactly that (which is *not* the KA
timeout). I think the prototypes should be something like
{code}
void releaseSession(HttpServerSession* ss, ink_hrtime ka_timeout_out = 0);
void HttpServerSession::release(ink_hrtime ka_timeout_out);
{code}
Maybe it's our naming convention that's confusing, but _in and _out here refers
to "incoming" connection vs "outgoing" connection, not if it's an in or out
variable.
> 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_alive2.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)
