[
https://issues.apache.org/jira/browse/TS-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486040#comment-14486040
]
Bryan Call edited comment on TS-3487 at 4/8/15 9:17 PM:
--------------------------------------------------------
[~sudheerv] is correct, there are two timers at the same time (activity and
inactivity). Activity timers are scheduled using the scheduler and inactivity
is a timestamp in the UnixNetVConnection and using the inactivity cop. ATS can
be compiled to use the scheduler for inactivity timeouts, but that is not the
default.
Relevant methods:
{code}
UnixNetVConnection::set_active_timeout()
UnixNetVConnection::set_inactivity_timeout()
{code}
If for some reason the inactivity timeout is not set a default one will be
(default_inactivity_timeout).
Just tracked down this code, so the inactivity will be canceled, but then
inactivity cop will set a default one:
{code}
// Now that we have gotten the user agent request, we can cancel
// the inactivity timeout associated with it. Note, however, that
// we must not cancel the inactivity timeout if the message
// contains a body (as indicated by the non-zero request_content_length
// field). This indicates that a POST operation is taking place and
// that the client is still sending data to the origin server. The
// origin server cannot reply until the entire request is received. In
// light of this dependency, TS must ensure that the client finishes
// sending its request and for this reason, the inactivity timeout
// cannot be cancelled.
if (ua_session && !t_state.hdr_info.request_content_length) {
ua_session->get_netvc()->cancel_inactivity_timeout();
}
{code}
was (Author: bcall):
[~sudheerv] is correct, there are two timers at the same time (activity and
inactivity). Activity timers are scheduled using the scheduler and inactivity
is a timestamp in the UnixNetVConnection and using the inactivity cop. ATS can
be compiled to use the scheduler for inactivity timeouts, but that is not the
default.
Relevant methods:
{code}
UnixNetVConnection::set_active_timeout()
UnixNetVConnection::set_inactivity_timeout()
{code}
The inactivity timeout should always be set. The inactivity timeout shouldn't
be canceled on any request and it should be reset to a newer timestamp when
there is activity. If for some reason the inactivity timeout is not set a
default one will be (default_inactivity_timeout).
Just tracked down this code, so the inactivity will be canceled, but then
inactivity cop will set a default one.
{code}
// Now that we have gotten the user agent request, we can cancel
// the inactivity timeout associated with it. Note, however, that
// we must not cancel the inactivity timeout if the message
// contains a body (as indicated by the non-zero request_content_length
// field). This indicates that a POST operation is taking place and
// that the client is still sending data to the origin server. The
// origin server cannot reply until the entire request is received. In
// light of this dependency, TS must ensure that the client finishes
// sending its request and for this reason, the inactivity timeout
// cannot be cancelled.
if (ua_session && !t_state.hdr_info.request_content_length) {
ua_session->get_netvc()->cancel_inactivity_timeout();
}
{code}
> 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)
