[
https://issues.apache.org/jira/browse/TS-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299038#comment-15299038
]
ASF subversion and git services commented on TS-3440:
-----------------------------------------------------
Commit 736009b973ad44ef4c7185f5f3bfb778903e4316 in trafficserver's branch
refs/heads/master from [~jacksontj]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=736009b ]
TS-3959: requests are retryable only if bytes were sent and there was no
connection error
The root issue that TS-4328 and TS-3440 were trying to fix was that ATS was too
aggressive in retries to origin (namely after the origin had already recieved
the request). The previous patches attempted to have ATS not retry assuming
bytes were sent on the wire-- sadly TS-4328 actually only checks that we set
bytes to be written to the wire. To fix this we simply check if there was a
connection failure to origin, if so we'll assume that it is retryable (since
connection failures to origin should only be due to errors writing/connecting
etc.).
> Connect_retries re-connects even if request made it to origin
> -------------------------------------------------------------
>
> Key: TS-3440
> URL: https://issues.apache.org/jira/browse/TS-3440
> Project: Traffic Server
> Issue Type: Bug
> Reporter: Thomas Jackson
> Assignee: Thomas Jackson
> Fix For: 6.0.0
>
>
> While trying to workaround TS-3439 I decided to test out the connect retries
> option. During testing I found a case where it should not retry where it is.
> The scenario is as follows:
> - ATS makes a connection to an origin
> - the origin acks the entire request
> - the origin starts to send back a response (lets say first line of the
> header)
> - the origin sends an RST
> In this scenario ATS will re-connect to the origin, which is bad since we
> have already sent the request (and we aren't sure if the URL is re-entrant).
> Test case:
> https://github.com/jacksontj/trafficserver/commit/28059ccb93f9fb173792aeebf90062882dfdf9d5#diff-06f9ddbe6cc45d76ebb2cb21479dc805R182
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
