[
https://issues.apache.org/jira/browse/TS-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518916#comment-14518916
]
Feifei Cai edited comment on TS-3487 at 4/29/15 7:57 AM:
---------------------------------------------------------
In my understanding of the current inactivity mechanism implementation,
*transaction_no_activity_timeout_in* only specifies the connections to client,
it does not relate to connections to origin server. That is to say, it only
count for timeout when a transaction stalls on client side connections. When we
disable I/O with client, the timer is set to 0, as follows:
{noformat}
read_disable/write_disable(NetHandler *nh, UnixNetVConnection *vc) {
…
vc->next_inactivity_timeout_at = 0;
…
}
{noformat}
Indeed, the inactivity mechanism is designed to ensure connections/resources
would not be held for too long and to prevent possible leaks. But we need
*transaction_no_activity_timeout_in* and *transaction_no_activity_timeout_out*
both, to control on the 2 directions. In your example - redirection scenarios,
I think it's just okay for client to be oblivious of 3xx follows that ATS
performs with origin server, because *transaction_no_activity_timeout_out*
timer would be responsible for the 3xx processes. If a transaction stalls on
*ATS <=> origin server* side, we should not abort connection on *client <=>
ATS* side (directly), it should trigger *ATS <=> origin server* side timeout
first, then abort this side connection, and at last, maybe abort the other side
connection according to some other logic.
We also use *accept_no_activity_timeout* to limit accept time, and
*connect_attempts_timeout* to limit connect time. These timeout is used earlier
than *transaction_no_activity_timeout_in/out*. When connection established,
*and*, start to read/write data on a connection, we update timer with
*transaction_no_activity_timeout_in/out* configurations. When stop to
read/write data on a connection, we clear the timer.
BTW, things changed slightly when we add *default_inactivity_timeout* setting.
As [~bcall] explained in his GET request example, "The inactivity timeout is
cleared because it is a GET and then reset to the default because there is none
set by inactivity cop." So, it should be possible for using (and relying solely
on) the *default_inactivity_timeout* timer independently to control two side
connections. However, I think this is a long time insurance, but not a short
time control. e.g. the default settings are as follows:
{noformat}
proxy.config.http.transaction_no_activity_timeout_in 30
proxy.config.http.transaction_no_activity_timeout_out 30
proxy.config.net.default_inactivity_timeout 86400
{noformat}
Ideally, with *transaction_no_activity_timeout_in* and
*transaction_no_activity_timeout_out* together, we should be able to ensure
connections time on both side and prevent leaks. I think we add a long time
*default_inactivity_timeout* setting because we have some unknown potential
bugs. With this setting, we can kill the connections which are idle too long.
was (Author: ffcai):
In my understanding of the current inactivity mechanism implementation,
*transaction_no_activity_timeout_in* only specifies the connections to client,
it does not relate to connections to origin server. That is to say, it only
count for timeout when a transaction stalls on client side connections. When we
disable I/O with client, the timer is set to 0, as follows:
{noformat}
read_disable/write_disable(NetHandler *nh, UnixNetVConnection *vc) {
…
vc->next_inactivity_timeout_at = 0;
…
}
{noformat}
Indeed, the inactivity mechanism is designed to ensure connections/resources
would not be held for too long and to prevent possible leaks. But we need
*transaction_no_activity_timeout_in* and *transaction_no_activity_timeout_out*
both, to control on the 2 directions. In your example - redirection scenarios,
I think it's just okay for client to be oblivious of 3xx follows that ATS
performs with origin server, because *transaction_no_activity_timeout_out*
timer would be responsible for the 3xx processes. If a transaction stalls on
*ATS <=> origin server* side, we should not abort connection on *client <=>
ATS* side (directly), it should trigger *ATS <=> origin server* side timeout
first, then abort this side connection, and at last, maybe abort the other side
connection according to some other logic.
We also use *accept_no_activity_timeout* to limit accept time, and
*connect_attempts_timeout* to limit connect time. These timeout is used earlier
than *transaction_no_activity_timeout_in/out*. When connection established,
*and*, start to read/write data on a connection, we update timer with
*transaction_no_activity_timeout_in/out* configurations. When stop to
read/write data on a connection, we clear the timer.
BTW, things changed slightly when we add *default_inactivity_timeout* setting.
As [~bcall] explained in his GET request example, "The inactivity timeout is
cleared because it is a GET and then reset to the default because there is none
set by inactivity cop." So, it should be possible for using (and relying solely
on) the *default_inactivity_timeout* timer independently to control two side
connections. However, I think this is a long time insurance, but not a short
time control. e.g. the default settings are as follows:
{noformat}
proxy.config.http.transaction_no_activity_timeout_in 30
proxy.config.http.transaction_no_activity_timeout_out 30
proxy.config.net.default_inactivity_timeout 86400
{noformat}
Ideally, with *transaction_no_activity_timeout_in* and
*transaction_no_activity_timeout_out* together, we should be able to ensure
connections time on both side and prevent leaks. I think we add a long time
*default_inactivity_timeout* setting because we have some unknown potential
bugs. With this setting, we can kill the connections which are idle too long.
> cannot override proxy.config.http.transaction_no_activity_timeout_in per
> remap rule for POST methold
> ----------------------------------------------------------------------------------------------------
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 5.2.1
> Reporter: Feifei Cai
> Assignee: Bryan Call
> Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING
> http_cs|http_ss|inactivity.*|socket
> {noformat}
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_remap_config():
> s = get_socket()
> log.info('start test per remap config...')
> try:
> # before remap
> s.send(url2)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(11) # < per remap config
> s.send(body1)
> time.sleep(13) # < per remap config
> s.send(body2)
> log.info('test per remap config: pass!')
> except IOError:
> log.info('test per remap config: fail!')
> response = s.recv(4096)
> print response
> if __name__ == '__main__':
> test_global_config()
> test_per_remap_config()
> {code}
> {{test_global_config()}} would pass, but {{test_per_remap_config()}} fails.
> {{proxy.config.http.transaction_no_activity_timeout_in}} in per remap rule
> does not works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
