[
https://issues.apache.org/jira/browse/TS-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749614#comment-13749614
]
Assaf Yaari commented on TS-1424:
---------------------------------
I've tried the attached patch for 3.2.x.
Unfortunately doing so causes the traffic_server to crash when I'm trying to
reproduce the scenario.
First I ran into to asserts that I tried to remark out:
The first assert is: "ink_assert(c->vc == ua_session);" in
HttpSM::tunnel_handler_ua.
The second assert is: "ink_assert(ua_entry->vc == c->vc);" in the same method.
Removing those two asserts didn't help as finally the traffic_server crashed
due to segfault:
(gdb) bt
#0 0x0000000000580eec in HttpClientSession::set_half_close_flag (this=0x0) at
HttpClientSession.h:66
#1 0x000000000056f3fe in HttpSM::tunnel_handler_ua (this=0x2b94a0250af0,
event=103, c=0x2b94a02526b0) at HttpSM.cc:3149
#2 0x00000000005b3c1c in HttpTunnel::consumer_handler (this=0x2b94a0252670,
event=103, c=0x2b94a02526b0) at HttpTunnel.cc:1243
#3 0x00000000005b4398 in HttpTunnel::main_handler (this=0x2b94a0252670,
event=103, data=0x2b94680159c0) at HttpTunnel.cc:1467
#4 0x00000000004e2714 in Continuation::handleEvent (this=0x2b94a0252670,
event=103, data=0x2b94680159c0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00000000006c21e2 in write_signal_and_update (event=103,
vc=0x2b9468015840) at UnixNetVConnection.cc:153
#6 0x00000000006c230b in write_signal_done (event=103, nh=0x2b945a3a71e8,
vc=0x2b9468015840) at UnixNetVConnection.cc:180
#7 0x00000000006c32d3 in write_to_net_io (nh=0x2b945a3a71e8,
vc=0x2b9468015840, thread=0x2b945a3a4010) at UnixNetVConnection.cc:480
#8 0x00000000006c2ba7 in write_to_net (nh=0x2b945a3a71e8, vc=0x2b9468015840,
pd=0x2b9464142010, thread=0x2b945a3a4010) at UnixNetVConnection.cc:352
#9 0x00000000006bef8e in NetHandler::mainNetEvent (this=0x2b945a3a71e8,
event=5, e=0x1149b30) at UnixNet.cc:388
#10 0x00000000004e2714 in Continuation::handleEvent (this=0x2b945a3a71e8,
event=5, data=0x1149b30) at ../iocore/eventsystem/I_Continuation.h:146
#11 0x00000000006e4b2c in EThread::process_event (this=0x2b945a3a4010,
e=0x1149b30, calling_code=5) at UnixEThread.cc:142
#12 0x00000000006e50d9 in EThread::execute (this=0x2b945a3a4010) at
UnixEThread.cc:264
#13 0x00000000006e3d6a in spawn_thread_internal (a=0x10e2100) at Thread.cc:88
#14 0x00000031b54077f1 in start_thread () from /lib64/libpthread.so.0
#15 0x00000031b50e570d in clone () from /lib64/libc.so.6
I will attach also the traffic.out.
I see that the commit to the master is somewhat different from the 3.2.x patch,
should I try it instead of the patch?
> Transparent proxy with proxy.config.http.use_client_source_port==1 has
> problems if the client is keep-alive and the origin server is not.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-1424
> URL: https://issues.apache.org/jira/browse/TS-1424
> Project: Traffic Server
> Issue Type: Bug
> Environment: 3.2 with transparent (TProxy) interception +
> proxy.config.http.use_client_source_port = 1
> Reporter: B Wyatt
> Assignee: Alan M. Carroll
> Fix For: 4.1.0
>
> Attachments: ts-1424-3-2-x.diff
>
>
> As keep-alive is hop-to-hop ATS will happily support client keep-alive in
> instances where an Origin Server terminates the connection after each
> transaction.
> However, when using proxy.config.http.use_client_source_port this behavior
> can cause some sites to break.
> When the client is kept alive, subsequent requests are made rapidly and with
> the same 4-tuple for addressing. Since ATS is trying to match the 4-tuple
> (due to proxy.config.http.use_client_source_port) it enters a 3-way race
> between:
> # the FIN, FIN/ACK packets being exchanged with the origin server and the new
> request packets from the client. If the OS is slow it is possible that ATS
> will attempt to reconnect with the same port/address before the connection is
> legitimately closed.
> # Kernel timers for PAWS and recently closed sockets. This is different (and
> much shorter) than the time-wait state and there is no way to disable it
> # Everything working out just fine and the connection establishing like normal
> The best repro case I've seen is a slow origin server that serves pages in
> <frame> tags from the same host but does not support keep-alive
> (http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp for
> instance)
> It is possible that simply respecting a servers keep-alive settings when
> using proxy.config.http.use_client_source_port would work as the original
> client would change the 4-tuple address for its next connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
