[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370303#comment-14370303
]
Dzmitry Markovich commented on TS-3312:
---
[~amc]
OK, i tested all release() calls and looks like the only one that matters is in
time in HttpSM::tunnel_handler_server. That simplifies all the things :) - we
simply set the timeout at that place once.
Please take a look at the patch keep_alive4.diff (it passes our tests).
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370387#comment-14370387
]
ASF subversion and git services commented on TS-3312:
-
Commit 88c12579737ad977e97afa70bb497c9b5340970d in trafficserver's branch
refs/heads/master from [~dmich]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=88c1257 ]
TS-3312: KA timeout to origin does not honor configs
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_alive4.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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14369510#comment-14369510
]
Alan M. Carroll commented on TS-3312:
-
Here's the code I have from {{HttpSessionPool::releaseSession}}
{code}
// we probably don't need the active timeout set, but will leave it for now
ss-get_netvc()-set_inactivity_timeout(ss-get_netvc()-get_inactivity_timeout());
ss-get_netvc()-set_active_timeout(ss-get_netvc()-get_active_timeout());
{code}
This just resets the timers, it doesn't change the values. So, if just prior to
this the timeouts are explicitly set to the keep_alive value, that will be
preserved. I looked at {{HttpServerSession::release}} and I don't see any code
that sets any of the timeouts.
It because {{HttpServerSession::release}} is called in multiple locations that
I think a distinct method should be called in {{HttpSM::tunnel_handler_server}}
to set the timeouts to the keep_alive timeouts so it is done only at that
location. I think it is unnecessary in the other locations because it will
persist across a call to {{HttpServerSession::release}}. It is this last that
seems to be the point of disagreement - can you point out the code there you
think sets the timeout values to the transaction timeout? I'm looking at master
currently.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367362#comment-14367362
]
Alan M. Carroll commented on TS-3312:
-
Yes. I think my recommendation is to not pass the time out via releaseSession()
but instead have another method which explicitly sets the timeouts and call
that from the HttpSM cleanup logic. This will cover anything put in the pool
*and* sticky sessions without convoluted logic. The keepalive value would be
easily accessible and overridable. I'd keep the timeout resetting
::releaseSession as they are now so you get a timer reset then but tweak the
time out value through a specific method.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367438#comment-14367438
]
Dzmitry Markovich commented on TS-3312:
---
[~amc] doing it in cleanup is not ideal as well. Since, when cleanup step is
executing - connection is already released to the pool (and inactivity timeout
already set). Even worse, some other transaction can technically acquire this
connection at the time we call HttpSM::cleanup().
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366754#comment-14366754
]
Dzmitry Markovich commented on TS-3312:
---
[~amc], currently when we return a connection to the pool (when we call
release() ) it sets it's inactivity timeout to transaction timeout, so if there
is no activity on this connection it will be closed after transaction timeout
(which is much smaller then keep alive timeout). The patch changes this
behavior and sets it to keep alive timeout. And when we will have an active
transaction on this connection the timeout will be updated with transaction
timeout again.
imagine:
transaction inactivity timeout = 10sec and keep alive timeout = 100sec
So before:
connection-transaction start- set inactivity timeout to 10sec -transaction
end-return connection to the pool- connection closed after 10 seconds
after the fix:
connection-transaction start- set inactivity timeout to 10sec -transaction
end-return connection to the pool- set inactivity timeout to 100 sec -
connection closed after 100 seconds
in case transaction not ends in 10 sec in both cases connection will be closed
after 10 secs.
So, technically we have to use both timeouts (transaction and keep alive). One
controls max time that connection can stay live with no activity on
activetransaction, and other one controls the max time connection can stay live
with out any active transactions.
Let me know if it make sense.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14368140#comment-14368140
]
Alan M. Carroll commented on TS-3312:
-
I meant cleanup generically rather than the specific method.
I looked over the code and I think if you set the times in
{{HttpSM::release_server_session}} right after {{session-attach_hostname}}
that would work.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366071#comment-14366071
]
Dzmitry Markovich commented on TS-3312:
---
[~zwoop], [~briang] - i fixed the naming and attached a patch.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366124#comment-14366124
]
Brian Geffon commented on TS-3312:
--
[~dmich] Thanks! I'll wait for [~amc] to throw out any last feedback and commit
it very soon.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365913#comment-14365913
]
Dzmitry Markovich commented on TS-3312:
---
[~briang], could you please take a look? I addressed feedback with previous
patch.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365935#comment-14365935
]
Brian Geffon commented on TS-3312:
--
I'm not thrilled that we have to modify the {{release()}} signature, but I see
why it's necessary. This looks good to me, if there are no other
objections/comments/suggestions I'll commit this latest version in the next few
days.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359982#comment-14359982
]
Dzmitry Markovich commented on TS-3312:
---
[~amc], [~zwoop] - thank you for clarifying. Now it is clear to me. I will
prepare a new patch and update this ticket.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359382#comment-14359382
]
Leif Hedstrom commented on TS-3312:
---
Yes, that seems right. Lets back this out, and redo.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359446#comment-14359446
]
Brian Geffon commented on TS-3312:
--
[~dmich], can you take a crack at Alan's suggestion?
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359317#comment-14359317
]
Alan M. Carroll commented on TS-3312:
-
I think the better option here would be to add a member to HttpServerSession
that holds the inactivity time out value and then set it in HttpSM::kill_this()
so that
* It gets passed in an overriddable way
* You don't have to lock the HttpConfig inside the session manager.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359703#comment-14359703
]
Alan M. Carroll commented on TS-3312:
-
If Dzmitry is confused then others will be as well.
The issue is the configuration overrides work by setting a value in a
substructure of {{HttpSM}}. In this case the code is located in the
HttpSessionManager release logic. By that point the {{HttpSM}} no longer exists
and therefore any overrides set during the transaction don't exist either and
can't be used. Effectively this means only the global from {{records.config}}
will ever be used. That is, the value is de facto not overriddable even though
the API lets you change it. The solution suggested is to wait until the last
possible moment and then, just before the {{HttpSM}} evaporates, copy the value
over to the {{HttpServerSession}} to be used which makes it overriddable.
What this value controls in this context is a limit on how long the server
session will be held in the session pool. The use case is to be able to control
that based on the server by tweaking this value during the transaction.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359708#comment-14359708
]
Leif Hedstrom commented on TS-3312:
---
That's correct. They way the overridable configs works is to copy the entire
oride struct from the global to the txn member of the HttpSM. In the original
patch it always used the global , it never even had a chance to use the txn
copy.
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359547#comment-14359547
]
Dzmitry Markovich commented on TS-3312:
---
Agree with HttpConfig::release. Maybe I'm missing something, but I don see how
it breaks previously overridable configuration into a non-overridable one?
I'll talk to Alan offline...
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357881#comment-14357881
]
Dzmitry Markovich commented on TS-3312:
---
I have a patch for this. Please review it an commit if it looks good.
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: 6.0.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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357892#comment-14357892
]
Brian Geffon commented on TS-3312:
--
[~dmich], thanks, that looks good.
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: 6.0.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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339644#comment-14339644
]
ASF subversion and git services commented on TS-3312:
-
Commit 1f25a8846c0cdf7cbd06b442c9fb1289026f439c in trafficserver's branch
refs/heads/master from Derek Bruce
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1f25a88 ]
TS-3312: Add tests based around this issue
This also merges the current tests to use mixins.
This closes #174
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339645#comment-14339645
]
ASF GitHub Bot commented on TS-3312:
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/174
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 dbr...@gmail.com
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)
[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations
[
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286509#comment-14286509
]
ASF subversion and git services commented on TS-3312:
-
Commit 0b7bf112a778111469f837a3fbba3982d217bb5d in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0b7bf11 ]
TS-153: Dynamic keep-alive timeouts
Renaming proxy.config.net.connections.threshold_shed_idle_in to
proxy.config.net.max_connections_in to be inline with the overall
design in TS-3312
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
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)
