[
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:18 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.
I'm proposing the following patch
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 59ee0fc..2deb330 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -3643,6 +3643,17 @@ HttpTransact::handle_response_from_server(State *s)
s->current.server->set_connect_fail(EUSERS); // too many users
handle_server_connection_not_open(s);
break;
+ case PARSE_ERROR:
+ /* fall through */
+ case BAD_INCOMING_RESPONSE: {
+ // this case should not be allowed to retry because we'll end up making
another request
+ DebugTxn("http_trans", "[handle_response_from_server] Transaction received
a bad response or a partial response, not retrying...");
+ SET_VIA_STRING(VIA_DETAIL_SERVER_CONNECT, VIA_DETAIL_SERVER_FAILURE);
+ handle_server_connection_not_open(s);
+ break;
+ }
+ case CONNECTION_CLOSED:
+ /* fall through */
case OPEN_RAW_ERROR:
/* fall through */
case CONNECTION_ERROR:
@@ -3650,12 +3661,6 @@ HttpTransact::handle_response_from_server(State *s)
case STATE_UNDEFINED:
/* fall through */
case INACTIVE_TIMEOUT:
- /* fall through */
- case PARSE_ERROR:
- /* fall through */
- case CONNECTION_CLOSED:
- /* fall through */
- case BAD_INCOMING_RESPONSE:
// Set to generic I/O error if not already set specifically.
if (!s->current.server->had_connect_fail())
s->current.server->set_connect_fail(EIO);
{code}
The behavior for the following situations will be:
- Server closes the connection and doesn't send back any data -> ATS RETRIES
according to config
- Server closes the connection after sending back malformed or partial headers
-> ATS DOESN'T RETRY
- Server close the connection after sending back well formed headers -> ATS
DOESN'T RETRY.
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.
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.
> 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)
