[
https://issues.apache.org/jira/browse/TS-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606939#comment-14606939
]
Brian Geffon edited comment on TS-3440 at 6/30/15 7:02 AM:
-----------------------------------------------------------
I'm actually unable to observe ATS making a second connection. Given your
current test ATS will simply return the 200 response to the client without a
body, but I actually never see ATS establish a second connection.
It appears in the case you originally proposed for testing this would fall
under server truncation and ATS _will not_ establish a new connection.
The case where ATS will attempt to re-establish a connection is when nothing is
received or an invalid response is received, for example, if the connection is
closed after ATS has received the request or if the connection is closed after
some portion of the headers are received such as "HTTP/1.1 200" and nothing
else, in the latter case it _should not_ establish a new connection as it's
known that the request was received. Unfortunately, there is no way for ATS to
know that the request was ACKed if no data was received back so we should retry
in that situation.
was (Author: briang):
I'm actually unable to observe ATS making a second connection. Given your
current test ATS will simply return the 200 response to the client without a
body, but I actually never see ATS establish a second connection.
It appears in the case you originally proposed for testing this would fall
under server truncation and ATS _will not_ establish a new connection.
> 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: Brian Geffon
> Fix For: sometime
>
>
> 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)
