[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-2729:
Attachment: http2-0002.patch
Attached http2-0002.patch.
This is a full patch based on current
master(56e83bda3639292d10cd403fe94254762560dc83).
It includes the all changes made by the attached patches and also includes
changes for TS-2746 (that conflicts with the first patch).
Add HTTP/2 support to ATS
-
Key: TS-2729
URL: https://issues.apache.org/jira/browse/TS-2729
Project: Traffic Server
Issue Type: New Feature
Components: HTTP/2
Reporter: Ryo OKUBO
Labels: review
Fix For: 5.0.0
Attachments: draft11.patch, draft12.patch,
fix-handling-version-string.patch, http2-0001.patch, http2-0002.patch,
ts2743.patch, ts2760.patch
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-10.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-10
Our implementation similar to the SPDY implementation in ATS core(TS-2431)
but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
for example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* Cleanup codes.
* Follow http2 draft-12 and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984173#comment-13984173 ] Shaun McGinnity commented on TS-2497: - Hi Brian, yes, it is a simple test simulating a server closing the connection before reading the complete post. I am sending a post with Content-Length: 310. The server reads 10 bytes and then closes the connection. I have added some debug. On a successful post HttpSM::tunnel_handler_post_or_put deallocates the buffers created for the post tunnel: Apr 29 11:04:10 - INFO - HttpSM::attach_client_session 0x10d5b980 0x10d5d598 Apr 29 11:04:10 - INFO - free_MIOBuffer 0x5001350 Apr 29 11:04:10 - INFO - free_MIOBuffer 0x5001350 DONE Apr 29 11:04:10 - INFO - HttpSM::do_setup_post_tunnel 0x10d5b980 add_producer : buffer 0x5001368 Apr 29 11:04:10 - INFO - HttpTunnel::add_producer : 0x10d5d598 buffer_start = 0x5001368 read_buffer = 0x5001350 Apr 29 11:05:29 - INFO - HttpSM::tunnel_handler_post_or_put : HTTP_SM_POST_SUCCESS deallocate_buffers 0x10d5d598 Apr 29 11:05:29 - INFO - 0x10d5d598 :: deallocate_buffers Apr 29 11:05:29 - INFO - 0x10d5d598 :: deallocate_buffers : free producers[0].read_buffer 0x5001350 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001350 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001350 DONE Apr 29 11:05:29 - INFO - HttpTunnel::reset 0x10d5d598 Apr 29 11:05:29 - INFO - HttpSM::setup_server_transfer 0x10d5b980 add_producer : buffer 0x5001368 Apr 29 11:05:29 - INFO - HttpTunnel::add_producer : 0x10d5d598 buffer_start = 0x5001368 read_buffer = 0x5001350 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 DONE Apr 29 11:05:29 - INFO - HttpSM::kill_this : deallocate_buffers 0x10d5d598 Apr 29 11:05:29 - INFO - 0x10d5d598 :: deallocate_buffers Apr 29 11:05:29 - INFO - 0x10d5d598 :: deallocate_buffers : free producers[0].read_buffer 0x5001350 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001350 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001350 DONE Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001710 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001710 DONE On a failed post the buffer used in the post tunnel is not freed: Apr 29 11:03:54 - INFO - HttpSM::attach_client_session 0x10d5b980 0x10d5d598 Apr 29 11:03:54 - INFO - free_MIOBuffer 0x5001440 Apr 29 11:03:54 - INFO - free_MIOBuffer 0x5001440 DONE Apr 29 11:03:54 - INFO - HttpSM::do_setup_post_tunnel 0x10d5b980 add_producer : buffer 0x5001458 Apr 29 11:03:54 - INFO - HttpTunnel::add_producer : 0x10d5d598 buffer_start = 0x5001458 read_buffer = 0x5001440 Apr 29 11:03:57 - INFO - HttpSM::tunnel_handler_post_or_put : HTTP_SM_POST_SERVER_FAIL 0x10d5d598 Apr 29 11:03:57 - INFO - HttpSM::handle_post_failure : 0x10d5d598 Apr 29 11:03:57 - INFO - ua_session-do_io_read Apr 29 11:03:57 - INFO - HttpTunnel::reset 0x10d5d598 Apr 29 11:03:57 - INFO - free_MIOBuffer 0x5001620 Apr 29 11:03:57 - INFO - free_MIOBuffer 0x5001620 DONE Apr 29 11:03:57 - INFO - HttpSM::setup_internal_transfer 0x10d5b980 add_producer : buffer 0x5001638 Apr 29 11:03:57 - INFO - HttpTunnel::add_producer : 0x10d5d598 buffer_start = 0x5001638 read_buffer = 0x5001620 Apr 29 11:03:57 - INFO - HttpSM::kill_this : deallocate_buffers 0x10d5d598 Apr 29 11:03:57 - INFO - 0x10d5d598 :: deallocate_buffers Apr 29 11:03:57 - INFO - 0x10d5d598 :: deallocate_buffers : free producers[0].read_buffer 0x5001620 Apr 29 11:03:57 - INFO - free_MIOBuffer 0x5001620 Apr 29 11:03:57 - INFO - free_MIOBuffer 0x5001620 DONE Apr 29 11:03:57 - INFO - free_MIOBuffer 0x5001710 Apr 29 11:03:57 - INFO - free_MIOBuffer 0x5001710 DONE Shaun Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984357#comment-13984357 ] James Peach commented on TS-2497: - [~shaunmcginnity] can you contribute the test to our regression suite? Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal (this=0x2aab38001130, b=0x2aab0c037200) at ../iocore/eventsystem/P_IOBuffer.h:946 #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:994 #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1002 #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1048 #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 #7 0x006c37bf in UnixNetVConnection::net_read_io (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at UnixNetVConnection.cc:816 #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, event=5, e=0x271d8e0) at UnixNet.cc:380 #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at UnixEThread.cc:264 #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2762) Core dump when benchmarking SPDY
Bryan Call created TS-2762:
--
Summary: Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2762) Core dump when benchmarking SPDY
[
https://issues.apache.org/jira/browse/TS-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2762:
---
Labels: spdy yahoo (was: )
Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
Assignee: Bryan Call
Labels: spdy, yahoo
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2728) the lib/perl Makefile.am does not properly detect in-source builds
[ https://issues.apache.org/jira/browse/TS-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2728: -- Summary: the lib/perl Makefile.am does not properly detect in-source builds (was: the lib/perl Makefile.am does not properly detect out-of-source builds) the lib/perl Makefile.am does not properly detect in-source builds -- Key: TS-2728 URL: https://issues.apache.org/jira/browse/TS-2728 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 It seems that the out-of-source builds for our Perl modules is somewhat confused. I think the tests are not correct, such that we try to cp the source tree even when we're doing an in-source build (which then makes cp complain that source and destination is the same). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2728) the lib/perl Makefile.am does not properly detect in-source builds
[
https://issues.apache.org/jira/browse/TS-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984525#comment-13984525
]
Leif Hedstrom commented on TS-2728:
---
This is the error we get
{code}
make[2]: Entering directory `/tmp/trafficserver-5.0.0/lib/perl'
[ . != ../../lib/perl ] cp -rf ./. ../../lib/perl
cp: ‘./.’ and ‘../../lib/perl/.’ are the same file
{code}
the lib/perl Makefile.am does not properly detect in-source builds
--
Key: TS-2728
URL: https://issues.apache.org/jira/browse/TS-2728
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
It seems that the out-of-source builds for our Perl modules is somewhat
confused. I think the tests are not correct, such that we try to cp the
source tree even when we're doing an in-source build (which then makes cp
complain that source and destination is the same).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2762) Core dump when benchmarking SPDY
[
https://issues.apache.org/jira/browse/TS-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2762:
--
Assignee: Bryan Call
Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
Assignee: Bryan Call
Labels: spdy, yahoo
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2743) Crash with SPDY on production environment in SpdyNV::SpdyNV
[ https://issues.apache.org/jira/browse/TS-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2743: --- Labels: spdy yahoo (was: SPDY_ATS) Crash with SPDY on production environment in SpdyNV::SpdyNV --- Key: TS-2743 URL: https://issues.apache.org/jira/browse/TS-2743 Project: Traffic Server Issue Type: Bug Components: Core, SPDY Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: spdy, yahoo Fix For: 5.0.0 Attachments: 0001-TS-2743-Ignore-invalid-HTTP-headers-in-SpdyNV-carefu.patch After patching a fix (by removing the apparent incorrect assert failure on non-ipv4 address in TsFetchCreate - jira ts-2742), noticed a new crash, this time in SpdyNV::SpdyNV with the below stack trace. Will update more upon investigation. FATAL: SpdyCommon.cc:133: failed assert `value value_len` FATAL: SpdyCommon.cc:133: failed assert `value value_len` /home/y/bin/traffic_server - STACK TRACE: /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8] /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f] /home/y/bin/traffic_server[0x4af739] /home/y/bin/traffic_server[0x5cf7ea] /home/y/bin/traffic_server[0x5d0a6a] /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a] /home/y/bin/traffic_server[0x4af739] /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37] /home/y/bin/traffic_server[0x5cf7ea] /home/y/bin/traffic_server[0x5d0a6a] /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a] /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37] /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb] /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5] /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a] /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb] /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272] /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f] /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab] /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272] /home/y/bin/traffic_server[0x71232a] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f] /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] /home/y/bin/traffic_server[0x71232a] /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2762) Core dump when benchmarking SPDY
[
https://issues.apache.org/jira/browse/TS-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2762:
---
Fix Version/s: 5.0.0
Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.0.0
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2762) Core dump when benchmarking SPDY
[
https://issues.apache.org/jira/browse/TS-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984528#comment-13984528
]
Bryan Call commented on TS-2762:
Simple fix:
{code}
diff --git a/proxy/http/HttpAcceptCont.cc b/proxy/http/HttpAcceptCont.cc
index d3744e7..b6cfff6 100644
--- a/proxy/http/HttpAcceptCont.cc
+++ b/proxy/http/HttpAcceptCont.cc
@@ -59,7 +59,7 @@ HttpAcceptCont::mainEvent(int event, void *data)
if (is_debug_tag_set(http_seq))
Debug(http_seq, [HttpAcceptCont:mainEvent %p] accepted connection
from %s transport type = %d, netvc, ats_ip_nptop(client_ip, ipb, sizeof(ipb)),
netvc-attributes);
-HttpClientSession *new_session =
THREAD_ALLOC_INIT(httpClientSessionAllocator, netvc-thread);
+HttpClientSession *new_session =
THREAD_ALLOC_INIT(httpClientSessionAllocator, this_ethread());
// copy over session related data.
new_session-f_outbound_transparent = f_outbound_transparent;
{code}
Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.0.0
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2762) Core dump when benchmarking SPDY
[
https://issues.apache.org/jira/browse/TS-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984556#comment-13984556
]
ASF subversion and git services commented on TS-2762:
-
Commit 5bfe7168306f1004a9114f2cc157036ca53e8663 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5bfe716 ]
TS-2762: Core dump when benchmarking SPDY
Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.0.0
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984558#comment-13984558 ] ASF subversion and git services commented on TS-1125: - Commit df0e9bb0537b460b418544cb67d57b20e63d1cd7 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=df0e9bb ] updated changes to add TS-2762 and remove TS-1125 POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff, ts1125.diff, ts1125.diff, ts1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2762) Core dump when benchmarking SPDY
[
https://issues.apache.org/jira/browse/TS-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984557#comment-13984557
]
ASF subversion and git services commented on TS-2762:
-
Commit df0e9bb0537b460b418544cb67d57b20e63d1cd7 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=df0e9bb ]
updated changes to add TS-2762 and remove TS-1125
Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.0.0
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent
[
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2750:
---
Labels: spdy yahoo (was: SPDY_ATS)
Crash with SPDY on production environment in HttpAcceptCont::mainEvent
--
Key: TS-2750
URL: https://issues.apache.org/jira/browse/TS-2750
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: spdy, yahoo
Fix For: sometime
After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/
a temporary fix still using the TS API, before a permanent fix is available),
noticed the below new core.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
/home/y/bin/traffic_server[0x5d263c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
/home/y/bin/traffic_server[0x5d0aa8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
/home/y/bin/traffic_server[0x71239a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent
[
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2750:
---
Fix Version/s: (was: sometime)
5.0.0
Crash with SPDY on production environment in HttpAcceptCont::mainEvent
--
Key: TS-2750
URL: https://issues.apache.org/jira/browse/TS-2750
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: spdy, yahoo
Fix For: 5.0.0
After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/
a temporary fix still using the TS API, before a permanent fix is available),
noticed the below new core.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
/home/y/bin/traffic_server[0x5d263c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
/home/y/bin/traffic_server[0x5d0aa8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
/home/y/bin/traffic_server[0x71239a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent
[
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-2750.
--
Resolution: Duplicate
Didn't see that this bug was already opened. I committed the fix in TS-2762.
Crash with SPDY on production environment in HttpAcceptCont::mainEvent
--
Key: TS-2750
URL: https://issues.apache.org/jira/browse/TS-2750
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: spdy, yahoo
Fix For: 5.0.0
After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/
a temporary fix still using the TS API, before a permanent fix is available),
noticed the below new core.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
/home/y/bin/traffic_server[0x5d263c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
/home/y/bin/traffic_server[0x5d0aa8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
/home/y/bin/traffic_server[0x71239a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2711) Include Lua JIT as a submodule
[ https://issues.apache.org/jira/browse/TS-2711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984569#comment-13984569 ] ASF subversion and git services commented on TS-2711: - Commit 3195b37ef5f2e0f7dc5180704fca5735487f06b8 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3195b37 ] TS-2711 fix in-source builds from tar-ball Include Lua JIT as a submodule --- Key: TS-2711 URL: https://issues.apache.org/jira/browse/TS-2711 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984574#comment-13984574 ] Brian Geffon commented on TS-2497: -- [~shaunmcginnity] I'll try to reproduce and get back to you. Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal (this=0x2aab38001130, b=0x2aab0c037200) at ../iocore/eventsystem/P_IOBuffer.h:946 #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:994 #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1002 #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1048 #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 #7 0x006c37bf in UnixNetVConnection::net_read_io (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at UnixNetVConnection.cc:816 #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, event=5, e=0x271d8e0) at UnixNet.cc:380 #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at UnixEThread.cc:264 #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2762) Core dump when benchmarking SPDY
[
https://issues.apache.org/jira/browse/TS-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-2762.
Resolution: Fixed
Core dump when benchmarking SPDY
Key: TS-2762
URL: https://issues.apache.org/jira/browse/TS-2762
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Bryan Call
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.0.0
The problems exist when trying to use the proxy allocator from a different
thread to allocate a HttpClientSession.
{code}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf750)[0x2b6270ec2750]
/usr/local/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x179)[0x50ee99]
/usr/local/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9f)[0x4d89af]
/usr/local/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x21)[0x4d8c81]
/usr/local/bin/traffic_server(TSHttpConnectWithProtoStack+0xb0)[0x4b8380]
/usr/local/bin/traffic_server(_ZN7FetchSM11httpConnectEv+0x28)[0x4c3be8]
/usr/local/bin/traffic_server[0x57a25a]
/usr/local/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x8
1c)[0x57b56c]
/usr/local/lib/libspdylay.so.7(spdylay_session_on_syn_stream_received+0x100)[0x2b62701cc010]
/usr/local/lib/libspdylay.so.7(spdylay_session_mem_recv+0xcb7)[0x2b62701ce4c7]
/usr/local/lib/libspdylay.so.7(spdylay_session_recv+0x51)[0x2b62701ce791]
/usr/local/bin/traffic_server[0x578aff]
/usr/local/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x34)[0x695564]
/usr/local/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xca1)[0x684cc1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x68c0e2]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0xad3)[0x6bbc63]
/usr/local/bin/traffic_server[0x6ba69a]
/lib64/libpthread.so.0(+0x7f33)[0x2b6270ebaf33]
/lib64/libc.so.6(clone+0x6d)[0x2b6271f56ded]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984585#comment-13984585 ] Brian Geffon edited comment on TS-2497 at 4/29/14 5:58 PM: --- [~shaunmcginnity], something is a little unclear to me, the only difference between the two is: Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 DONE Which happens after add_producer, can you provide a back trace or something for those two frees? It's not clear where they are coming from, also, are you sure this behavior didn't exist before? Can you also provide output from -T .* debug tag? was (Author: briang): [~shaunmcginnity], something is a little unclear to me, the only difference between the two is: Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 DONE Which happens after add_producer, can you provide a back trace or something for those two frees? It's not clear where they are coming from, also, are you sure this behavior didn't exist before? Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal (this=0x2aab38001130, b=0x2aab0c037200) at ../iocore/eventsystem/P_IOBuffer.h:946 #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:994 #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1002 #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1048 #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 #7 0x006c37bf in UnixNetVConnection::net_read_io (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at UnixNetVConnection.cc:816 #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, event=5, e=0x271d8e0) at UnixNet.cc:380 #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at UnixEThread.cc:264 #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984585#comment-13984585 ] Brian Geffon commented on TS-2497: -- [~shaunmcginnity], something is a little unclear to me, the only difference between the two is: Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 Apr 29 11:05:29 - INFO - free_MIOBuffer 0x5001620 DONE Which happens after add_producer, can you provide a back trace or something for those two frees? It's not clear where they are coming from, also, are you sure this behavior didn't exist before? Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal (this=0x2aab38001130, b=0x2aab0c037200) at ../iocore/eventsystem/P_IOBuffer.h:946 #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:994 #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1002 #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1048 #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 #7 0x006c37bf in UnixNetVConnection::net_read_io (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at UnixNetVConnection.cc:816 #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, event=5, e=0x271d8e0) at UnixNet.cc:380 #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at UnixEThread.cc:264 #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2644) TOS (DSCP)
[ https://issues.apache.org/jira/browse/TS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Tomolek updated TS-2644: Attachment: domain_tos.cc Here's the plugin code Cheers, JT TOS (DSCP) --- Key: TS-2644 URL: https://issues.apache.org/jira/browse/TS-2644 Project: Traffic Server Issue Type: New Feature Components: Cache, Network Reporter: Faysal Banna Fix For: 5.0.0 Attachments: domain_tos.cc Hi Guys I wonder if it would be possible to have a plugin that we can assign TOS/DSCP bits to the objects that are being a cache HIT or maybe object type of video/audio. such a plugin would give us better performance and control on how to distribute the output of the cache towards clients. example : suppose i set traffic to clients each of different bandwidth. on a router on a link somewhere on some roof top building i can say this client can get miss object traffic of 512Kbit/s and 1Mbit/s of Hits from the cache. this way if this client is getting a cached object he would get it in 1Mbit/s while his non cached requests would be of 512Kbit/s hope whoever does this patch plugin takes into consideration the mime type or url of the object being retrieved maybe i want to set audio/video being cached or not to have 768Kbit/s while windows updates and android/iphone apps should take no more than 512kbit/s bear in mind that this has nothing to do with Origin servers throttling feature request. this is just client side feature set. much regards Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984753#comment-13984753 ] Shaun McGinnity commented on TS-2497: - hi Brian, here is the debug with the buffer allocation locations recorded: Apr 29 21:13:29 - INFO - HttpSM::attach_client_session 0x10613980 0x10615598 Apr 29 21:13:29 - INFO - free_MIOBuffer 0x49b5530 memory/IOBuffer/HttpSM.cc:5575 -- setup_server_send_request Apr 29 21:13:29 - INFO - free_MIOBuffer 0x49b5530 DONE Apr 29 21:13:29 - INFO - HttpSM::do_setup_post_tunnel 0x10613980 add_producer : buffer 0x49b5548 Apr 29 21:13:29 - INFO - HttpTunnel::add_producer : 0x10615598 buffer_start = 0x49b5548 read_buffer = 0x49b5530 Apr 29 21:14:47 - INFO - HttpSM::tunnel_handler_post_or_put : HTTP_SM_POST_SUCCESS deallocate_buffers 0x10615598 Apr 29 21:14:47 - INFO - 0x10615598 :: deallocate_buffers Apr 29 21:14:47 - INFO - 0x10615598 :: deallocate_buffers : free producers[0].read_buffer 0x49b5530 Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5530 memory/IOBuffer/HttpSM.cc:5259 -- do_setup_post_tunnel Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5530 DONE Apr 29 21:14:47 - INFO - HttpTunnel::reset 0x10615598 Apr 29 21:14:47 - INFO - HttpSM::setup_server_transfer 0x10613980 add_producer : buffer 0x49b5548 Apr 29 21:14:47 - INFO - HttpTunnel::add_producer : 0x10615598 buffer_start = 0x49b5548 read_buffer = 0x49b5530 Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5620 memory/IOBuffer/HttpServerSession.cc:87-- HttpServerSession::new_connection Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5620 DONE Apr 29 21:14:47 - INFO - HttpSM::kill_this : deallocate_buffers 0x10615598 Apr 29 21:14:47 - INFO - 0x10615598 :: deallocate_buffers Apr 29 21:14:47 - INFO - 0x10615598 :: deallocate_buffers : free producers[0].read_buffer 0x49b5530 Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5530 memory/IOBuffer/HttpSM.cc:6189 -- setup_server_transfer Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5530 DONE Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5710 memory/IOBuffer/HttpClientSession.cc:237 -- HttpClientSession::new_connection Apr 29 21:14:47 - INFO - free_MIOBuffer 0x49b5710 DONE Post failure: Apr 29 21:32:08 - INFO - HttpSM::attach_client_session 0x11869980 0x1186b598 Apr 29 21:32:08 - INFO - free_MIOBuffer 0x5c37530 memory/IOBuffer/HttpSM.cc:5575 -- setup_server_send_request Apr 29 21:32:08 - INFO - free_MIOBuffer 0x5c37530 DONE Apr 29 21:32:08 - INFO - HttpSM::do_setup_post_tunnel 0x11869980 add_producer : buffer 0x5c37548 Apr 29 21:32:08 - INFO - HttpTunnel::add_producer : 0x1186b598 buffer_start = 0x5c37548 read_buffer = 0x5c37530 Apr 29 21:32:11 - INFO - HttpSM::tunnel_handler_post_or_put : HTTP_SM_POST_SERVER_FAIL 0x1186b598 Apr 29 21:32:11 - INFO - HttpSM::handle_post_failure : 0x1186b598 Apr 29 21:32:11 - INFO - ua_session-do_io_read Apr 29 21:32:11 - INFO - HttpTunnel::reset 0x1186b598 Apr 29 21:32:11 - INFO - free_MIOBuffer 0x5c37620 memory/IOBuffer/HttpServerSession.cc:87 -- HttpServerSession::new_connection Apr 29 21:32:11 - INFO - free_MIOBuffer 0x5c37620 DONE Apr 29 21:32:11 - INFO - HttpSM::setup_internal_transfer 0x11869980 add_producer : buffer 0x5c37638 Apr 29 21:32:11 - INFO - HttpTunnel::add_producer : 0x1186b598 buffer_start = 0x5c37638 read_buffer = 0x5c37620 Apr 29 21:32:11 - INFO - HttpSM::kill_this : deallocate_buffers 0x1186b598 Apr 29 21:32:11 - INFO - 0x1186b598 :: deallocate_buffers Apr 29 21:32:11 - INFO - 0x1186b598 :: deallocate_buffers : free producers[0].read_buffer 0x5c37620 Apr 29 21:32:11 - INFO - free_MIOBuffer 0x5c37620 memory/IOBuffer/HttpSM.cc:5889 -- HttpSM::setup_internal_transfer Apr 29 21:32:11 - INFO - free_MIOBuffer 0x5c37620 DONE Apr 29 21:32:11 - INFO - free_MIOBuffer 0x5c37710 memory/IOBuffer/HttpClientSession.cc:237 -- HttpClientSession::new_connection Apr 29 21:32:11 - INFO - free_MIOBuffer 0x5c37710 DONE There are 4 frees compared to 5 in the successful case. The buffer that is not freed is created in HttpSM::do_setup_post_tunnel. With the change removed i.e. call made to HttpTunnel deallocate_buffers in handle_post_failure then we get 5 frees. Apr 29 21:21:51 - INFO - HttpSM::attach_client_session 0x10613980 0x10615598 Apr 29 21:21:51 - INFO - free_MIOBuffer 0x49b5620 memory/IOBuffer/HttpSM.cc:5575 -- setup_server_send_request Apr 29 21:21:51 - INFO - free_MIOBuffer 0x49b5620 DONE Apr 29 21:21:51 - INFO - HttpSM::do_setup_post_tunnel 0x10613980 add_producer : buffer 0x49b5638 Apr 29 21:21:51 - INFO - HttpTunnel::add_producer : 0x10615598 buffer_start = 0x49b5638 read_buffer = 0x49b5620 Apr 29 21:21:54 - INFO - HttpSM::tunnel_handler_post_or_put : HTTP_SM_POST_SERVER_FAIL 0x10615598 Apr 29 21:21:54 - INFO - HttpSM::handle_post_failure : 0x10615598 Apr 29 21:21:54 - INFO - ua_session-do_io_read Apr 29 21:21:54 - INFO - 0x10615598 :: deallocate_buffers Apr 29 21:21:54 - INFO - 0x10615598
[jira] [Created] (TS-2763) remove proxy.config.log.xuid_logging_enabled
James Peach created TS-2763:
---
Summary: remove proxy.config.log.xuid_logging_enabled
Key: TS-2763
URL: https://issues.apache.org/jira/browse/TS-2763
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: James Peach
{{proxy.config.log.xuid_logging_enabled}} is long dead. Let's remove the
configuration variable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2763) remove proxy.config.log.xuid_logging_enabled
[
https://issues.apache.org/jira/browse/TS-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2763:
Priority: Minor (was: Major)
Fix Version/s: 5.0.0
Assignee: James Peach
remove proxy.config.log.xuid_logging_enabled
Key: TS-2763
URL: https://issues.apache.org/jira/browse/TS-2763
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 5.0.0
{{proxy.config.log.xuid_logging_enabled}} is long dead. Let's remove the
configuration variable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2763) remove proxy.config.log.xuid_logging_enabled
[
https://issues.apache.org/jira/browse/TS-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984874#comment-13984874
]
ASF subversion and git services commented on TS-2763:
-
Commit 6f92984f5c406c84347dc9fa23eda4d95587ddf2 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6f92984 ]
TS-2763: remove unused proxy.config.log.xuid_logging_enabled
remove proxy.config.log.xuid_logging_enabled
Key: TS-2763
URL: https://issues.apache.org/jira/browse/TS-2763
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 5.0.0
{{proxy.config.log.xuid_logging_enabled}} is long dead. Let's remove the
configuration variable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2763) remove proxy.config.log.xuid_logging_enabled
[
https://issues.apache.org/jira/browse/TS-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2763.
-
Resolution: Fixed
remove proxy.config.log.xuid_logging_enabled
Key: TS-2763
URL: https://issues.apache.org/jira/browse/TS-2763
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 5.0.0
{{proxy.config.log.xuid_logging_enabled}} is long dead. Let's remove the
configuration variable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2757) deleting stale API logs always crashes
[
https://issues.apache.org/jira/browse/TS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984891#comment-13984891
]
James Peach commented on TS-2757:
-
I think that this crash is caused by the silly dance that {{LogObjectManager}}
does when reloading the logging configuration. I can reproduce similar problems
by running moderate traffic while reloading the logging configuration a lot.
The only way to fix all of these issues is to add full reference counting to
{{LogObject}}. I have a patch that implements that and it has been running the
test above safely for a few hours now.
deleting stale API logs always crashes
--
Key: TS-2757
URL: https://issues.apache.org/jira/browse/TS-2757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 5.0.0
Reporter: James Peach
Assignee: James Peach
Labels: A
If you use {{TSTextLogObjectCreate}} in a plugin, when those log objects are
deleted, the object manager crashes. It looks like {{_APIobjects}} has a
stale pointer.
{code}
(gdb) bt
#0 0x005e8c47 in LogObjectManager::~LogObjectManager
(this=0x4bf0028, __in_chrg=value optimized out) at LogObject.cc:903
#1 0x005d33e2 in LogConfig::~LogConfig (this=0x4bf,
__in_chrg=value optimized out) at LogConfig.cc:573
#2 0x005d3446 in LogConfig::~LogConfig (this=0x4bf,
__in_chrg=value optimized out) at LogConfig.cc:573
#3 0x00617b8a in ConfigProcessor::release (this=0xafa720, id=5,
info=0x4bf) at ProxyConfig.cc:210
#4 0x00618496 in ConfigInfoReleaser::handle_event (this=0x21c5a00)
at ProxyConfig.cc:106
#5 0x004e5920 in Continuation::handleEvent (this=0x21c5a00, event=2,
data=0xe926780) at ../iocore/eventsystem/I_Continuation.h:146
#6 0x006d17b6 in EThread::process_event (this=0x2e08000,
e=0xe926780, calling_code=2) at UnixEThread.cc:145
#7 0x006d1ad1 in EThread::execute (this=0x2e08000) at
UnixEThread.cc:224
#8 0x006d0da0 in spawn_thread_internal (a=0x21ddd60) at Thread.cc:88
#9 0x2b507e273851 in start_thread () from /lib64/libpthread.so.0
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryo OKUBO updated TS-2729:
--
Description:
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431) but
we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, for
example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* Cleanup codes.
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
*
was:
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-10.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-10
Our implementation similar to the SPDY implementation in ATS core(TS-2431) but
we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, for
example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* Cleanup codes.
* Follow http2 draft-12 and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
Add HTTP/2 support to ATS
-
Key: TS-2729
URL: https://issues.apache.org/jira/browse/TS-2729
Project: Traffic Server
Issue Type: New Feature
Components: HTTP/2
Reporter: Ryo OKUBO
Labels: review
Fix For: 5.0.0
Attachments: draft11.patch, draft12.patch,
fix-handling-version-string.patch, http2-0001.patch, http2-0002.patch,
ts2743.patch, ts2760.patch
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431)
but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
for example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* Cleanup codes.
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
*
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryo OKUBO updated TS-2729:
--
Description:
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431) but
we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, for
example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* Cleanup codes.
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
** it'll refer to configuration settings for SPDY on TS-2740
was:
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431) but
we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, for
example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* Cleanup codes.
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
*
Add HTTP/2 support to ATS
-
Key: TS-2729
URL: https://issues.apache.org/jira/browse/TS-2729
Project: Traffic Server
Issue Type: New Feature
Components: HTTP/2
Reporter: Ryo OKUBO
Labels: review
Fix For: 5.0.0
Attachments: draft11.patch, draft12.patch,
fix-handling-version-string.patch, http2-0001.patch, http2-0002.patch,
ts2743.patch, ts2760.patch
h2. Overview
We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
experimentally.
Now, it supports HTTP/2 draft-12.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
Our implementation similar to the SPDY implementation in ATS core(TS-2431)
but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
https://github.com/tatsuhiro-t/nghttp2
We tested NPN and ALPN negotiation.
h2. How to test it
* Install nghttp2 library, here is URL of this library:
https://github.com/tatsuhiro-t/nghttp2
* Use '--enable-http2' option to compile ATS:
{noformat}
$ ./configure --enable-http2
$ make all make install
{noformat}
* You can use '--with-openssl=dir' option.
* Need not configure anything if you just want to test HTTP/2 without SSL.
The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
requests.
* You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
for example:
{noformat}
# HTTP/2 without SSL
$ nghttp -v http://localhost/b.txt
# HTTP/2 + SSL
$ nghttp -v https://localhost/b.txt
{noformat}
h2. TODO
* Cleanup codes.
* Follow -http2 draft-12- and later.
* -Support ALPN.-
* Add settings related to HTTP/2 into records.config.
** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2736) Use more file descriptors by default
[ https://issues.apache.org/jira/browse/TS-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13985101#comment-13985101 ] ASF subversion and git services commented on TS-2736: - Commit 7ff90360b6ccf7debf7489bff6caa56e11181c06 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7ff9036 ] TS-2736: Fix build on ignored return value. Use more file descriptors by default Key: TS-2736 URL: https://issues.apache.org/jira/browse/TS-2736 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.0.0 Currently our connection throttling setting limits the total number of FD's that ATS can use. In addition it has pro-active code that stops taking connections as that limit is approached. So we can theoretically use more FD's than we request and still have that setting be effective. Additionally epoll can use a lot of FD's if we use it for things like AIO and timers. Modern Linux systems have many millions of FD's available. I think we should use more FD's by default but have a setting that we can lower it back down. I propose the default be 90%. -- This message was sent by Atlassian JIRA (v6.2#6252)
