[
https://issues.apache.org/jira/browse/TS-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496241#comment-14496241
]
Sudheer Vinukonda edited comment on TS-3487 at 4/15/15 3:07 PM:
----------------------------------------------------------------
*proxy.config.http.transaction_no_activity_timeout_in* has been defined as
*Specifies how long Traffic Server keeps connections to clients open if a
transaction stalls.*
*https://docs.trafficserver.apache.org/en/latest/reference/configuration/records.config.en.html#proxy-config-http-transaction-no-activity-timeout-in*
The definition by itself covers the entire transaction and does not indicate
that it is only activated/run when there's i/o with the client. IMHO, it should
be possible for using (and relying solely on) this timer independently (i.e.
without defining *proxy.config.http.transaction_no_activity_timeout_out* and
even the activity timers) to ensure the connections/resources are not held for
too long and to prevent (possible) leaks.
For example, consider the scenario where there's a 3XX redirect response from
the Origin and ATS is configured to allow redirect follow upto *N* times. The
client is oblivious of the 3XX follow that ATS is performing and the
transaction from the client's side does not have a timer (assuming, there's no
active timeout). This is made worse when the origin connection alone takes a
long time (due to the connect timer and the reattempts). The latter is true
even without a redirect follow scenario.
Note also that there are control frames in H2 (and SPDY) which may cause the
default inactivity timer from *not* expiring.
Having said that, I do agree (like I also mentioned in my last comment) there's
little value in trying to override the timer for GET, since, it is almost rare
that the active timers are not configured.
was (Author: sudheerv):
*proxy.config.http.transaction_no_activity_timeout_in* has been defined as
*Specifies how long Traffic Server keeps connections to clients open if a
transaction stalls.*
*https://docs.trafficserver.apache.org/en/latest/reference/configuration/records.config.en.html#proxy-config-http-transaction-no-activity-timeout-in*
The definition by itself covers the entire transaction and does not indicate
that it is only activated/run when there's i/o with the client. IMHO, it should
be possible for using (and relying solely on) this timer independently (i.e.
without defining *proxy.config.http.transaction_no_activity_timeout_out* and
even the activity timers).
For example, consider the scenario where there's a 3XX redirect response from
the Origin and ATS is configured to allow redirect follow upto *N* times. The
client is oblivious of the 3XX follow that ATS is performing and the
transaction from the client's side does not have a timer (assuming, there's no
active timeout). Note also that there are control frames in H2 (and SPDY) which
may cause the default inactivity timer from *not* expiring.
Having said that, I do agree (like I also mentioned in my last comment) there's
little value in trying to override the timer for GET, since, it is almost rare
that the active timers are not configured.
> 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)
