[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14337402#comment-14337402
]
ASF GitHub Bot commented on TS-3312:
------------------------------------
GitHub user dfu opened a pull request:
https://github.com/apache/trafficserver/pull/174
TS-3312: Add keep alive activity timeout and min origin connection tests
This also merges the current tests to use mixins, so that we don't have to
replicate them when using SSL.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dfu/trafficserver timeout_tests
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/174.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #174
----
commit d7a260c3647d1e0b2840378bcedaf1b80837e356
Author: Derek Bruce <[email protected]>
Date: 2015-02-25T22:42:16Z
TS-3312: Add tests based around this issue
This also merges the current tests to use mixins.
----
> 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
>
>
> 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)
