[
https://issues.apache.org/jira/browse/TS-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253795#comment-14253795
]
Sudheer Vinukonda commented on TS-3189:
---------------------------------------
Tried the attached patch, but, it crashes with the below stack trace.
{code}
gdb) bt
#0 0x0000003296e328a5 in raise () from /lib64/libc.so.6
#1 0x0000003296e3400d in abort () from /lib64/libc.so.6
#2 0x00002b94a49ab868 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x00002b94a49ab932 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, fmt=0x2b94a49bb5c0 "%s:%d: failed assert
`%s`", ap=0x2b95620537f0)
at ink_error.cc:67
#4 0x00002b94a49ab9fb in ink_fatal (return_code=1,
message_format=0x2b94a49bb5c0 "%s:%d: failed assert `%s`") at ink_error.cc:75
#5 0x00002b94a49a9404 in _ink_assert (expression=0x7a7386 "0", file=0x7a737c
"HttpSM.cc", line=1993) at ink_assert.cc:37
#6 0x00000000005dc589 in HttpSM::state_send_server_request_header
(this=0x2b95dd453a90, event=102, data=0x2b9614017c68) at HttpSM.cc:1993
#7 0x00000000005de696 in HttpSM::main_handler (this=0x2b95dd453a90, event=102,
data=0x2b9614017c68) at HttpSM.cc:2566
#8 0x0000000000502eae in Continuation::handleEvent (this=0x2b95dd453a90,
event=102, data=0x2b9614017c68) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x00000000007523f7 in read_signal_and_update (event=102, vc=0x2b9614017b50)
at UnixNetVConnection.cc:138
#10 0x0000000000752552 in read_signal_done (event=102, nh=0x2b956073fad0,
vc=0x2b9614017b50) at UnixNetVConnection.cc:169
#11 0x0000000000754c08 in UnixNetVConnection::readSignalDone
(this=0x2b9614017b50, event=102, nh=0x2b956073fad0) at UnixNetVConnection.cc:922
#12 0x000000000073db02 in SSLNetVConnection::net_read_io (this=0x2b9614017b50,
nh=0x2b956073fad0, lthread=0x2b956073c010) at SSLNetVConnection.cc:488
#13 0x000000000074c441 in NetHandler::mainNetEvent (this=0x2b956073fad0,
event=5, e=0x1e3a970) at UnixNet.cc:399
#14 0x0000000000502eae in Continuation::handleEvent (this=0x2b956073fad0,
event=5, data=0x1e3a970) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x000000000077307a in EThread::process_event (this=0x2b956073c010,
e=0x1e3a970, calling_code=5) at UnixEThread.cc:144
#16 0x0000000000773584 in EThread::execute (this=0x2b956073c010) at
UnixEThread.cc:268
#17 0x0000000000772635 in spawn_thread_internal (a=0x23fb750) at Thread.cc:88
#18 0x00002b94a5051851 in start_thread () from /lib64/libpthread.so.0
#19 0x0000003296ee890d in clone () from /lib64/libc.so.6
(gdb) frame 6
#6 0x00000000005dc589 in HttpSM::state_send_server_request_header
(this=0x2b95dd453a90, event=102, data=0x2b9614017c68) at HttpSM.cc:1993
1993 HttpSM.cc: No such file or directory.
in HttpSM.cc
(gdb) print server_sessop
No symbol "server_sessop" in current context.
(gdb) print server_session
$1 = (HttpServerSession *) 0x2b95e0026220
(gdb) print server_session->read_buffer
$2 = (MIOBuffer *) 0x2b95c8001540
(gdb) print event
$3 = 102
{code}
Discussed further with [~shinrich] and modified the patch to only fix the
{{do_io_read}} in {{attach_client_session}} to pass non-null buffer. The
{{do_io_read}} in {{attach_server_session}} shouldn't have any active reads at
this point, so, passing NULL there should be fine.
The new patch with the below diff seems fine so far. Will monitor and update
further.
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index 5f07f8c..c8a011d 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -575,7 +575,7 @@ HttpSM::attach_client_session(HttpClientSession *
client_vc, IOBufferReader * bu
// this hook maybe asynchronous, we need to disable IO on
// client but set the continuation to be the state machine
// so if we get an timeout events the sm handles them
- ua_entry->read_vio = client_vc->do_io_read(this, 0, NULL);
+ ua_entry->read_vio = client_vc->do_io_read(this, 0, buffer_reader->mbuf);
/////////////////////////
// set up timeouts //
{code}
> Do not start reading data on server to user agent tunnel too soon
> -----------------------------------------------------------------
>
> Key: TS-3189
> URL: https://issues.apache.org/jira/browse/TS-3189
> Project: Traffic Server
> Issue Type: Bug
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
> Attachments: ts-3189.diff
>
>
> The original logic would set up a do_io_read for max_int in
> HttpSM::attach_server_session.
> However, at this point there still may be things finishing up in the
> user_agent to server tunnel (for posts). We were seeing occasional cases of
> the EOS for the tunnel to user_agent communication being incorrectly
> delivered to the consumer of the user_agent to server tunnel.
> It is sufficient to set up a 0 length read in HttpSM::attach_server_session.
> This will enable the correct handlers to deal with inactivity timeouts. Then
> we can setup the real read in HttpSM::setup_server_read_response_header()
> after we know that the user_agent to origin server tunnel has been taken
> down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
