[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366291#comment-14366291
]
Alan M. Carroll commented on TS-3312:
-------------------------------------
I'm going to rain on this parade because that's just how I roll.
It's unclear to me this bug even exists. What, exactly, is the problem? One is
resetting the timeout. But that's not a bug, it's a feature, as described in
the message itself - "reseting timeout to maintain minimum number of
connections", exactly as required by setting the configuration option
{{origin_min_keep_alive_connections}} to 10. It's done twice because the
inactivity timeout is set to 30s and we see the resets occuring at 30 and 60
seconds after being put in the pool. The connection then gets an EOS which
indicates the origin server shut it down. This occurs 60 seconds after the
session is put in the pool, again exactly as expected if the origin server has
a 60 second timeout.
On to poor Dzmitry. The primary issue I see is tieing the inactivity setting to
releasing the session. This is not the same as ending the transaction. In
particular the changes around line 4735 are going to happen after the
transaction has been destroyed and a new one created so any changes made in the
current transaction should *not* apply to that server session, as it is
associated almost certainly with a different origin (if not, it would have been
re-used instead of put in to the pool). So this is simply wrong.
To make any more criticism requires asking what exactly are we trying to do
here? If it's to propagate settings from a particular HttpSM into the server
session used by the HttpSM (because those settings may have been changed during
the HttpSM run based on transaction specific data) then we should do that at
the end of the HttpSM and not necessarily when it is put in to the pool. After
all, may we not want that to apply even for the sticky session case noted
above? So that if no new transaction does show up on the client session, the
server session times out as indicated by the default or the API supplied value?
What might be simpler and more accurately implement the desired behavior
(presuming we can even agree on that) is to have a seperate method on
HttpServerSession that sets the time out and have the HttpSM call that just
before the place where the server session can be released.
This leads to a related question. If the API is used to change the inactivity
timeout, when does that take effect? Is the timeout for the server session
immediately updated? If so then perhaps the HttpSM clean should just call that.
Otherwise would that be a bug with regard to what is expected to happen?
> 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)
