trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bc...@apache.org
Subject [trafficserver] 01/03: In the non-transparent case handle EADDRNOTAVAIL as a normal connect fail.
Date Wed, 06 Jun 2018 20:22:10 GMT
This is an automated email from the ASF dual-hosted git repository.

bcall pushed a commit to branch 8.0.x
in repository https://gitbox.apache.org/repos/asf/trafficserver.git

commit 302d5a8f08a1ed66446acec0de84577008d2cf3e
Author: Susan Hinrichs <shinrich@apache.org>
AuthorDate: Wed May 30 15:29:25 2018 -0500

    In the non-transparent case handle EADDRNOTAVAIL as a normal connect fail.
    
    (cherry picked from commit 5847c804b7fe374aeff27ccee6e68bf7afb5ca47)
---
 proxy/http/HttpSM.cc | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index ade8f1f..918a2b0 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -1764,14 +1764,14 @@ HttpSM::state_http_server_open(int event, void *data)
     // save the errno from the connect fail for future use (passed as negative value, flip
back)
     t_state.current.server->set_connect_fail(event == NET_EVENT_OPEN_FAILED ? -reinterpret_cast<intptr_t>(data)
: ECONNABORTED);
 
-    /* If we get this error, then we simply can't bind to the 4-tuple to make the connection.
 There's no hope of
-       retries succeeding in the near future. The best option is to just shut down the connection
without further
-       comment. The only known cause for this is outbound transparency combined with use
client target address / source
-       port, as noted in TS-1424. If the keep alives desync the current connection can be
attempting to rebind the 4
-       tuple simultaneously with the shut down of an existing connection. Dropping the client
side will cause it to pick
-       a new source port and recover from this issue.
+    /* If we get this error in transparent mode, then we simply can't bind to the 4-tuple
to make the connection.  There's no hope
+       of retries succeeding in the near future. The best option is to just shut down the
connection without further comment. The
+       only known cause for this is outbound transparency combined with use client target
address / source port, as noted in
+       TS-1424. If the keep alives desync the current connection can be attempting to rebind
the 4 tuple simultaneously with the
+       shut down of an existing connection. Dropping the client side will cause it to pick
a new source port and recover from this
+       issue.
     */
-    if (EADDRNOTAVAIL == t_state.current.server->connect_result) {
+    if (EADDRNOTAVAIL == t_state.current.server->connect_result && t_state.client_info.is_transparent)
{
       if (is_debug_tag_set("http_tproxy")) {
         ip_port_text_buffer ip_c, ip_s;
         Debug("http_tproxy", "Force close of client connect (%s->%s) due to EADDRNOTAVAIL
[%" PRId64 "]",

-- 
To stop receiving notification emails like this one, please contact
bcall@apache.org.

Mime
View raw message