[jira] [Commented] (TS-3265) core dump in spdy_prepare_status_response_and_clean_request
[
https://issues.apache.org/jira/browse/TS-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259902#comment-14259902
]
Yunkai Zhang commented on TS-3265:
--
Cool, nice catch!
core dump in spdy_prepare_status_response_and_clean_request
---
Key: TS-3265
URL: https://issues.apache.org/jira/browse/TS-3265
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Affects Versions: 5.2.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.3.0
Noticed the below core dump in v5.2.0.
{code}
(gdb) bt
#0 0x00638442 in std::vectorstd::pairstd::basic_stringchar,
std::char_traitschar, std::allocatorchar , std::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
std::allocatorstd::pairstd::basic_stringchar, std::char_traitschar,
std::allocatorchar , std::basic_stringchar, std::char_traitschar,
std::allocatorchar::size (
this=0x38) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_vector.h:533
#1 0x0063667e in spdy_prepare_status_response_and_clean_request
(sm=0x2ad800d4d730, stream_id=1, status=0x7b6b4d 500 Internal Server Error)
at SpdyCallbacks.cc:57
#2 0x0063373c in spdy_process_fetch (event=TS_EVENT_ERROR,
sm=0x2ad800d4d730, edata=0x2ad818105c50) at SpdyClientSession.cc:350
#3 0x00633151 in SpdyClientSession::state_session_readwrite
(this=0x2ad800d4d730, event=3, edata=0x2ad818105c50) at
SpdyClientSession.cc:253
#4 0x00502eae in Continuation::handleEvent (this=0x2ad800d4d730,
event=3, data=0x2ad818105c50) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00501116 in FetchSM::InvokePluginExt (this=0x2ad818105c50,
fetch_event=3) at FetchSM.cc:245
#6 0x00501e59 in FetchSM::process_fetch_write (this=0x2ad818105c50,
event=3) at FetchSM.cc:495
#7 0x00501f3e in FetchSM::fetch_handler (this=0x2ad818105c50,
event=3, edata=0x2ad86c90b960) at FetchSM.cc:511
#8 0x00502eae in Continuation::handleEvent (this=0x2ad818105c50,
event=3, data=0x2ad86c90b960) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x0053e9d5 in PluginVC::process_write_side (this=0x2ad86c90b810,
other_side_call=false) at PluginVC.cc:519
#10 0x0053dbcd in PluginVC::main_handler (this=0x2ad86c90b810,
event=2, data=0x2ad80802c690) at PluginVC.cc:210
#11 0x00502eae in Continuation::handleEvent (this=0x2ad86c90b810,
event=2, data=0x2ad80802c690) at ../iocore/eventsystem/I_Continuation.h:146
#12 0x00773136 in EThread::process_event (this=0x2ad6cc10,
e=0x2ad80802c690, calling_code=2) at UnixEThread.cc:144
#13 0x00773451 in EThread::execute (this=0x2ad6cc10) at
UnixEThread.cc:223
#14 0x007726f1 in spawn_thread_internal (a=0x161fd50) at Thread.cc:88
#15 0x2ad6c6d30851 in start_thread () from /lib64/libpthread.so.0
#16 0x003296ee890d in clone () from /lib64/libc.so.6
{code}
Looking at the core in gdb, it seems the {{req}} object extracted from the
{{sm-req_map}} based on {{stream_id}} is null. However, the {{req}} object
(extracted from {{TSFetchUserDataGet}}) from the caller
{{spdy_process_fetch}} in frame#2 seems valid. Unfortunately, the core was
deleted before I could examine more info (like, the sm object's req_map or
the req object details etc).
{code}
(gdb) frame 1
#1 0x0063667e in spdy_prepare_status_response_and_clean_request
(sm=0x2ad800d4d730, stream_id=1, status=0x7b6b4d 500 Internal Server Error)
at SpdyCallbacks.cc:57
57SpdyCallbacks.cc: No such file or directory.
in SpdyCallbacks.cc
(gdb) print req
$1 = (SpdyRequest *) 0x0
(gdb) up
#2 0x0063373c in spdy_process_fetch (event=TS_EVENT_ERROR,
sm=0x2ad800d4d730, edata=0x2ad818105c50) at SpdyClientSession.cc:350
350 SpdyClientSession.cc: No such file or directory.
in SpdyClientSession.cc
(gdb) print req
$2 = (SpdyRequest *) 0x2ad7c4e8be90
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3083) crash
[
https://issues.apache.org/jira/browse/TS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258672#comment-14258672
]
Yunkai Zhang commented on TS-3083:
--
Yes, from the core dump after enable DEBUG, it obviously shows that
{{FetchSM::InvokePluginExt}}-{{FetchSM::cleanUp}} causing the double-free,
that is why {{pChunk-item_magic}} was corrupted.
I have a look at the code, [~sudheerv]'s patch should work for this issue.
But I think the lock is too big, we can use CAS() to modify {{destroyed}}
variable:)
crash
-
Key: TS-3083
URL: https://issues.apache.org/jira/browse/TS-3083
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.2.0
Reporter: bettydramit
Assignee: Zhao Yongming
Priority: Blocker
Labels: crash
Fix For: sometime
c++filt a.txt
{code}
/lib64/libpthread.so.0(+0xf710)[0x2b4c37949710]
/usr/lib64/trafficserver/libtsutil.so.5(ink_atomiclist_pop+0x3e)[0x2b4c35abb64e]
/usr/lib64/trafficserver/libtsutil.so.5(reclaimable_freelist_new+0x65)[0x2b4c35abc065]
/usr/bin/traffic_server(MIOBuffer_tracker::operator()(long)+0x2b)[0x4a33db]
/usr/bin/traffic_server(PluginVCCore::init()+0x2e3)[0x4d9903]
/usr/bin/traffic_server(PluginVCCore::alloc()+0x11d)[0x4dcf4d]
/usr/bin/traffic_server(TSHttpConnectWithPluginId+0x5d)[0x4b9e9d]
/usr/bin/traffic_server(FetchSM::httpConnect()+0x74)[0x4a0224]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4da675]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4dafca]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x315)[0x4dc9a5]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73788f]
/usr/bin/traffic_server(EThread::execute()+0x57b)[0x7381fb]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3083) crash
[
https://issues.apache.org/jira/browse/TS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258673#comment-14258673
]
Yunkai Zhang commented on TS-3083:
--
Yes, from the core dump after enable DEBUG, it obviously shows that
{{FetchSM::InvokePluginExt}}-{{FetchSM::cleanUp}} causing the double-free,
that is why {{pChunk-item_magic}} was corrupted.
I have a look at the code, [~sudheerv]'s patch should work for this issue.
But I think the lock is too big, we can use CAS() to modify {{destroyed}}
variable:)
crash
-
Key: TS-3083
URL: https://issues.apache.org/jira/browse/TS-3083
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.2.0
Reporter: bettydramit
Assignee: Zhao Yongming
Priority: Blocker
Labels: crash
Fix For: sometime
c++filt a.txt
{code}
/lib64/libpthread.so.0(+0xf710)[0x2b4c37949710]
/usr/lib64/trafficserver/libtsutil.so.5(ink_atomiclist_pop+0x3e)[0x2b4c35abb64e]
/usr/lib64/trafficserver/libtsutil.so.5(reclaimable_freelist_new+0x65)[0x2b4c35abc065]
/usr/bin/traffic_server(MIOBuffer_tracker::operator()(long)+0x2b)[0x4a33db]
/usr/bin/traffic_server(PluginVCCore::init()+0x2e3)[0x4d9903]
/usr/bin/traffic_server(PluginVCCore::alloc()+0x11d)[0x4dcf4d]
/usr/bin/traffic_server(TSHttpConnectWithPluginId+0x5d)[0x4b9e9d]
/usr/bin/traffic_server(FetchSM::httpConnect()+0x74)[0x4a0224]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4da675]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4dafca]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x315)[0x4dc9a5]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73788f]
/usr/bin/traffic_server(EThread::execute()+0x57b)[0x7381fb]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (TS-3083) crash
[
https://issues.apache.org/jira/browse/TS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-3083:
-
Comment: was deleted
(was: Yes, from the core dump after enable DEBUG, it obviously shows that
{{FetchSM::InvokePluginExt}}-{{FetchSM::cleanUp}} causing the double-free,
that is why {{pChunk-item_magic}} was corrupted.
I have a look at the code, [~sudheerv]'s patch should work for this issue.
But I think the lock is too big, we can use CAS() to modify {{destroyed}}
variable:))
crash
-
Key: TS-3083
URL: https://issues.apache.org/jira/browse/TS-3083
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.2.0
Reporter: bettydramit
Assignee: Zhao Yongming
Priority: Blocker
Labels: crash
Fix For: sometime
c++filt a.txt
{code}
/lib64/libpthread.so.0(+0xf710)[0x2b4c37949710]
/usr/lib64/trafficserver/libtsutil.so.5(ink_atomiclist_pop+0x3e)[0x2b4c35abb64e]
/usr/lib64/trafficserver/libtsutil.so.5(reclaimable_freelist_new+0x65)[0x2b4c35abc065]
/usr/bin/traffic_server(MIOBuffer_tracker::operator()(long)+0x2b)[0x4a33db]
/usr/bin/traffic_server(PluginVCCore::init()+0x2e3)[0x4d9903]
/usr/bin/traffic_server(PluginVCCore::alloc()+0x11d)[0x4dcf4d]
/usr/bin/traffic_server(TSHttpConnectWithPluginId+0x5d)[0x4b9e9d]
/usr/bin/traffic_server(FetchSM::httpConnect()+0x74)[0x4a0224]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4da675]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4dafca]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x315)[0x4dc9a5]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73788f]
/usr/bin/traffic_server(EThread::execute()+0x57b)[0x7381fb]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3083) crash
[
https://issues.apache.org/jira/browse/TS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258672#comment-14258672
]
Yunkai Zhang edited comment on TS-3083 at 12/25/14 7:51 AM:
Yes, from the core dump after enable DEBUG, it obviously shows that
{{FetchSM::InvokePluginExt = FetchSM::cleanUp}} causing the double-free, that
is why {{pChunk-item_magic}} was corrupted.
I have a look at the code, [~sudheerv]'s patch should work for this issue.
But I think the lock is too big, we can use CAS() to modify {{destroyed}}
variable:)
was (Author: yunkai):
Yes, from the core dump after enable DEBUG, it obviously shows that
{{FetchSM::InvokePluginExt}}-{{FetchSM::cleanUp}} causing the double-free,
that is why {{pChunk-item_magic}} was corrupted.
I have a look at the code, [~sudheerv]'s patch should work for this issue.
But I think the lock is too big, we can use CAS() to modify {{destroyed}}
variable:)
crash
-
Key: TS-3083
URL: https://issues.apache.org/jira/browse/TS-3083
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.2.0
Reporter: bettydramit
Assignee: Zhao Yongming
Priority: Blocker
Labels: crash
Fix For: sometime
c++filt a.txt
{code}
/lib64/libpthread.so.0(+0xf710)[0x2b4c37949710]
/usr/lib64/trafficserver/libtsutil.so.5(ink_atomiclist_pop+0x3e)[0x2b4c35abb64e]
/usr/lib64/trafficserver/libtsutil.so.5(reclaimable_freelist_new+0x65)[0x2b4c35abc065]
/usr/bin/traffic_server(MIOBuffer_tracker::operator()(long)+0x2b)[0x4a33db]
/usr/bin/traffic_server(PluginVCCore::init()+0x2e3)[0x4d9903]
/usr/bin/traffic_server(PluginVCCore::alloc()+0x11d)[0x4dcf4d]
/usr/bin/traffic_server(TSHttpConnectWithPluginId+0x5d)[0x4b9e9d]
/usr/bin/traffic_server(FetchSM::httpConnect()+0x74)[0x4a0224]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4da675]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4dafca]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x315)[0x4dc9a5]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73788f]
/usr/bin/traffic_server(EThread::execute()+0x57b)[0x7381fb]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3083) crash
[
https://issues.apache.org/jira/browse/TS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14138448#comment-14138448
]
Yunkai Zhang commented on TS-3083:
--
It's usually caused by double-free or overflow in upper layer.
You can add #define DEBUG in {{ink_queue_ext.h}} to enable double-free
checking temporarily.
crash
-
Key: TS-3083
URL: https://issues.apache.org/jira/browse/TS-3083
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.0.2
Reporter: bettydramit
Labels: crash
c++filt a.txt
{code}
/lib64/libpthread.so.0(+0xf710)[0x2b4c37949710]
/usr/lib64/trafficserver/libtsutil.so.5(ink_atomiclist_pop+0x3e)[0x2b4c35abb64e]
/usr/lib64/trafficserver/libtsutil.so.5(reclaimable_freelist_new+0x65)[0x2b4c35abc065]
/usr/bin/traffic_server(MIOBuffer_tracker::operator()(long)+0x2b)[0x4a33db]
/usr/bin/traffic_server(PluginVCCore::init()+0x2e3)[0x4d9903]
/usr/bin/traffic_server(PluginVCCore::alloc()+0x11d)[0x4dcf4d]
/usr/bin/traffic_server(TSHttpConnectWithPluginId+0x5d)[0x4b9e9d]
/usr/bin/traffic_server(FetchSM::httpConnect()+0x74)[0x4a0224]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4da675]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4dafca]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x315)[0x4dc9a5]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73788f]
/usr/bin/traffic_server(EThread::execute()+0x57b)[0x7381fb]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-2994) Make use of SO_REUSEPORT socket option
Yunkai Zhang created TS-2994: Summary: Make use of SO_REUSEPORT socket option Key: TS-2994 URL: https://issues.apache.org/jira/browse/TS-2994 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang One of the features merged in the 3.9 development cycle was TCP and UDP support for the SO_REUSEPORT socket option; that support was implemented in a series of patches by Tom Herbert. The new socket option allows multiple sockets on the same host to bind to the same port, and is intended to improve the performance of multithreaded network server applications running on top of multicore systems. --[The SO_REUSEPORT socket option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2994) Make use of SO_REUSEPORT socket option
[ https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091653#comment-14091653 ] Yunkai Zhang commented on TS-2994: -- Yes, the description from the link is clear enough for why we should make use of it:). And we have tested this option in Nginx, it can avoid *thundering herd* thoroughly, and play excellent performance on accepting connections. Make use of SO_REUSEPORT socket option -- Key: TS-2994 URL: https://issues.apache.org/jira/browse/TS-2994 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang Fix For: 6.0.0 One of the features merged in the 3.9 development cycle was TCP and UDP support for the SO_REUSEPORT socket option; that support was implemented in a series of patches by Tom Herbert. The new socket option allows multiple sockets on the same host to bind to the same port, and is intended to improve the performance of multithreaded network server applications running on top of multicore systems. --[The SO_REUSEPORT socket option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2895) memory allocation failure
[
https://issues.apache.org/jira/browse/TS-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060009#comment-14060009
]
Yunkai Zhang edited comment on TS-2895 at 7/13/14 5:59 AM:
---
According the system log, it's irrelevant to reclaimable freelist. The failure
was caused by {{ats_memalign()}}.
There are so many reasons could cause this issue:
1) The system memory is ran out?
2) If not, what cause so many memory fragmentations?
To diagnose, we need more context.
was (Author: yunkai):
According the system log, it's irrelevant to reclaimable freelist. The failure
was caused by {{ats_memalign()}}.
memory allocation failure
-
Key: TS-2895
URL: https://issues.apache.org/jira/browse/TS-2895
Project: Traffic Server
Issue Type: Test
Components: Cache, Clustering
Reporter: wangjun
Assignee: Zhao Yongming
Labels: crash
Fix For: sometime
Attachments: screenshot-1.jpg, screenshot-2.jpg
In this version(ats 4.0.2), I encountered a bug (memory allocation failure),
Look at the system log, screenshots below(screenshot-1.jpg).
Look at the program logs, screenshots below((screenshot-2.jpg).
Please help me, thank you.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2895) memory allocation failure
[
https://issues.apache.org/jira/browse/TS-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060009#comment-14060009
]
Yunkai Zhang commented on TS-2895:
--
According the system log, it's irrelevant to reclaimable freelist. The failure
was caused by {{ ats_memalign() }}.
memory allocation failure
-
Key: TS-2895
URL: https://issues.apache.org/jira/browse/TS-2895
Project: Traffic Server
Issue Type: Test
Components: Cache, Clustering
Reporter: wangjun
Assignee: Zhao Yongming
Labels: crash
Fix For: sometime
Attachments: screenshot-1.jpg, screenshot-2.jpg
In this version(ats 4.0.2), I encountered a bug (memory allocation failure),
Look at the system log, screenshots below(screenshot-1.jpg).
Look at the program logs, screenshots below((screenshot-2.jpg).
Please help me, thank you.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2742) Crash with SPDY on production environment in TsFetchCreate()
[ https://issues.apache.org/jira/browse/TS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990212#comment-13990212 ] Yunkai Zhang commented on TS-2742: -- Yes. Crash with SPDY on production environment in TsFetchCreate() Key: TS-2742 URL: https://issues.apache.org/jira/browse/TS-2742 Project: Traffic Server Issue Type: Bug Components: Core, SPDY Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: review, spdy, yahoo Fix For: 5.0.0 Attachments: 0001-TS-2742-FetchSM-can-accept-both-IPv4-and-IPv6-now.patch Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990217#comment-13990217
]
Yunkai Zhang commented on TS-2780:
--
[~bcall]:
I think this issue should be kept unresolved status before finding out the root
cause:
Why {{req_map}} contains unexpected NULL values?
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.0.0
Attachments: ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2767) ATS Memory Leak related to SPDY
[
https://issues.apache.org/jira/browse/TS-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987611#comment-13987611
]
Yunkai Zhang commented on TS-2767:
--
Ah, sorry, I'm also not an STL expert:(
Totally agree to remove STL, they just be used for quickly implementation.
ATS Memory Leak related to SPDY
---
Key: TS-2767
URL: https://issues.apache.org/jira/browse/TS-2767
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: SPDY_ATS, yahoo
Fix For: 5.0.0
Attachments: ts2767.diff
During production testing of SPDY, we noticed ATS's memory quickly grows to
about 20g RES and 31g VIRT and eventually becomes unresponsive. dstat shows a
lot of disk/paging activity.
Running Valgrind on a single request (using spdycat) shows the below possible
leaks.
{code}
==23000== 103 bytes in 1 blocks are possibly lost in loss record 3,133 of
3,823
==23000==at 0x4C285BC: operator new(unsigned long)
(vg_replace_malloc.c:298)
==23000==by 0x72CC3C8: std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocatorchar const) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CD19A: std::string::_Rep::_M_clone(std::allocatorchar
const, unsigned long) (in /usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CD5EB: std::string::reserve(unsigned long) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CDABE: std::string::append(std::string const) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x5D28DE: spdy_fetcher_launch(SpdyRequest*, TSFetchMethod)
(basic_string.h:2165)
==23000==by 0x5D379D: spdy_on_ctrl_recv_callback(spdylay_session*,
spdylay_frame_type, spdylay_frame*, void*) (SpdyCallbacks.cc:294)
==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
(spdylay_session.c:1782)
==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
(SpdySM.cc:263)
==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int)
(I_Continuation.h:146)
==23000==
==23000== 128 bytes in 1 blocks are possibly lost in loss record 3,256 of
3,823
==23000==at 0x4C285BC: operator new(unsigned long)
(vg_replace_malloc.c:298)
==23000==by 0x5D3C8E: std::vectorstd::pairstd::string, std::string,
std::allocatorstd::pairstd::string, std::string
::_M_insert_aux(__gnu_cxx::__normal_iteratorstd::pairstd::string,
std::string*, std::vectorstd::pairstd::string, std::string,
std::allocatorstd::pairstd::string, std::string ,
std::pairstd::string, std::string const) (new_allocator.h:89)
==23000==by 0x5D32CF: spdy_on_ctrl_recv_callback(spdylay_session*,
spdylay_frame_type, spdylay_frame*, void*) (stl_vector.h:741)
==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
(spdylay_session.c:1782)
==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
(SpdySM.cc:263)
==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int)
(I_Continuation.h:146)
==23000==by 0x6DC779: SSLNetVConnection::net_read_io(NetHandler*,
EThread*) (SSLNetVConnection.cc:294)
==23000==by 0x6E39F1: NetHandler::mainNetEvent(int, Event*)
(UnixNet.cc:384)
==23000==by 0x71059E: EThread::process_event(Event*, int)
(I_Continuation.h:146)
==23000==by 0x710DCA: EThread::execute() (UnixEThread.cc:269)
==23000==
==23000== 173 bytes in 5 blocks are possibly lost in loss record 3,303 of
3,823
==23000==at 0x4C285BC: operator new(unsigned long)
(vg_replace_malloc.c:298)
==23000==by 0x72CC3C8: std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocatorchar const) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CCDE4: ??? (in /usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CCF32: std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::basic_string(char const*, std::allocatorchar
const) (in /usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x5D32A2: spdy_on_ctrl_recv_callback(spdylay_session*,
spdylay_frame_type, spdylay_frame*, void*) (stl_pair.h:101)
==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
(spdylay_session.c:1782)
==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
(SpdySM.cc:263)
==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int
[jira] [Commented] (TS-2767) ATS Memory Leak related to SPDY
[
https://issues.apache.org/jira/browse/TS-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987269#comment-13987269
]
Yunkai Zhang commented on TS-2767:
--
Why not use {{string.clear()}} ? I bet it should be more efficient than
{{string.swap()}}
{code}
void
SpdyRequest::clear()
{
...
url.clear();
...
}
{code}
ATS Memory Leak related to SPDY
---
Key: TS-2767
URL: https://issues.apache.org/jira/browse/TS-2767
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: SPDY_ATS, yahoo
Fix For: 5.0.0
Attachments: ts2767.diff
During production testing of SPDY, we noticed ATS's memory quickly grows to
about 20g RES and 31g VIRT and eventually becomes unresponsive. dstat shows a
lot of disk/paging activity.
Running Valgrind on a single request (using spdycat) shows the below possible
leaks.
{code}
==23000== 103 bytes in 1 blocks are possibly lost in loss record 3,133 of
3,823
==23000==at 0x4C285BC: operator new(unsigned long)
(vg_replace_malloc.c:298)
==23000==by 0x72CC3C8: std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocatorchar const) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CD19A: std::string::_Rep::_M_clone(std::allocatorchar
const, unsigned long) (in /usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CD5EB: std::string::reserve(unsigned long) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CDABE: std::string::append(std::string const) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x5D28DE: spdy_fetcher_launch(SpdyRequest*, TSFetchMethod)
(basic_string.h:2165)
==23000==by 0x5D379D: spdy_on_ctrl_recv_callback(spdylay_session*,
spdylay_frame_type, spdylay_frame*, void*) (SpdyCallbacks.cc:294)
==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
(spdylay_session.c:1782)
==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
(SpdySM.cc:263)
==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int)
(I_Continuation.h:146)
==23000==
==23000== 128 bytes in 1 blocks are possibly lost in loss record 3,256 of
3,823
==23000==at 0x4C285BC: operator new(unsigned long)
(vg_replace_malloc.c:298)
==23000==by 0x5D3C8E: std::vectorstd::pairstd::string, std::string,
std::allocatorstd::pairstd::string, std::string
::_M_insert_aux(__gnu_cxx::__normal_iteratorstd::pairstd::string,
std::string*, std::vectorstd::pairstd::string, std::string,
std::allocatorstd::pairstd::string, std::string ,
std::pairstd::string, std::string const) (new_allocator.h:89)
==23000==by 0x5D32CF: spdy_on_ctrl_recv_callback(spdylay_session*,
spdylay_frame_type, spdylay_frame*, void*) (stl_vector.h:741)
==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
(spdylay_session.c:1782)
==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
(SpdySM.cc:263)
==23000==by 0x6EC1A6: UnixNetVConnection::readSignalAndUpdate(int)
(I_Continuation.h:146)
==23000==by 0x6DC779: SSLNetVConnection::net_read_io(NetHandler*,
EThread*) (SSLNetVConnection.cc:294)
==23000==by 0x6E39F1: NetHandler::mainNetEvent(int, Event*)
(UnixNet.cc:384)
==23000==by 0x71059E: EThread::process_event(Event*, int)
(I_Continuation.h:146)
==23000==by 0x710DCA: EThread::execute() (UnixEThread.cc:269)
==23000==
==23000== 173 bytes in 5 blocks are possibly lost in loss record 3,303 of
3,823
==23000==at 0x4C285BC: operator new(unsigned long)
(vg_replace_malloc.c:298)
==23000==by 0x72CC3C8: std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocatorchar const) (in
/usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CCDE4: ??? (in /usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x72CCF32: std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::basic_string(char const*, std::allocatorchar
const) (in /usr/lib64/libstdc++.so.6.0.13)
==23000==by 0x5D32A2: spdy_on_ctrl_recv_callback(spdylay_session*,
spdylay_frame_type, spdylay_frame*, void*) (stl_pair.h:101)
==23000==by 0x715E9F: spdylay_session_on_syn_stream_received
(spdylay_session.c:1782)
==23000==by 0x716BA6: spdylay_session_mem_recv (spdylay_session.c:2246)
==23000==by 0x716DD8: spdylay_session_recv (spdylay_session.c:2828)
==23000==by 0x5D0E57: spdy_default_handler(tsapi_cont*, TSEvent, void*)
(SpdySM.cc:263)
==23000==by 0x6EC1A6
[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=13985236#comment-13985236
]
Yunkai Zhang commented on TS-2762:
--
Nice catch!
When working with SPDY, Multiple FetchSM of one SPDY session may be executed
concurrently, as a result, THREAD_ALLOC_INIT() called by FetchSM could be in
race condition in the old 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-2746) undo accept continuation renaming
[ https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983925#comment-13983925 ] Yunkai Zhang commented on TS-2746: -- nice naming. undo accept continuation renaming - Key: TS-2746 URL: https://issues.apache.org/jira/browse/TS-2746 Project: Traffic Server Issue Type: Bug Components: Cleanup, SPDY Reporter: James Peach Assignee: James Peach Fix For: 5.0.0 In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we added the Cont suffix to everything that was a continuation, there would be no other suffixes. We should undo this, or find a new naming convention. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13983945#comment-13983945
]
Yunkai Zhang commented on TS-2750:
--
It seems the freelist of memory pool was corrupt.
You can use reclaimable freelist to help you find out potential double-free
issue or memory overflow.
By default, double-free checking of reclaimable freelist is disable. You can
enable it in two ways:
1) Compiles ATS with both {{\-\-enable-reclaimable-freelist}} and
{{\-\-enable-debug}} option, but unfortunately, {{\-\-enable-debug}} will
enable all debug assert in the whole project, which may introduce some bad
side-effect. So I would suggest:
2) Define DEBUG = 1 in {{ink_queue_ext.h}} header, and compiles ATS with
{{\-\-enable-reclaimable-freelist}}.
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_ATS
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] [Comment Edited] (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:comment-tabpanelfocusedCommentId=13983945#comment-13983945
]
Yunkai Zhang edited comment on TS-2750 at 4/29/14 3:33 AM:
---
It seems the freelist of memory pool was corrupt.
You can use reclaimable freelist to help you find out potential double-free
issue or memory overflow.
By default, double-free checking of reclaimable freelist is disable. You can
enable it in two ways:
1) Compiles ATS with both {{\-\-enable-reclaimable-freelist}} and
{{\-\-enable-debug}} option, but unfortunately, {{\-\-enable-debug}} will
enable all debug assert in the whole project, which may introduce some bad
side-effect. So I would suggest:
2) Define {{#define DEBUG}} macro in {{ink_queue_ext.h}} header, and compiles
ATS with {{\-\-enable-reclaimable-freelist}}.
was (Author: yunkai):
It seems the freelist of memory pool was corrupt.
You can use reclaimable freelist to help you find out potential double-free
issue or memory overflow.
By default, double-free checking of reclaimable freelist is disable. You can
enable it in two ways:
1) Compiles ATS with both {{\-\-enable-reclaimable-freelist}} and
{{\-\-enable-debug}} option, but unfortunately, {{\-\-enable-debug}} will
enable all debug assert in the whole project, which may introduce some bad
side-effect. So I would suggest:
2) Define DEBUG = 1 in {{ink_queue_ext.h}} header, and compiles ATS with
{{\-\-enable-reclaimable-freelist}}.
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_ATS
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] [Commented] (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:comment-tabpanelfocusedCommentId=13983969#comment-13983969
]
Yunkai Zhang commented on TS-2750:
--
Don't care spdylay library, the crashed backtrace show that freelist was messed
up.
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_ATS
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-2742) Crash with SPDY on production environment in TsFetchCreate()
[ https://issues.apache.org/jira/browse/TS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2742: - Attachment: 0001-TS-2742-FetchSM-can-accept-both-IPv4-and-IPv6-now.patch Crash with SPDY on production environment in TsFetchCreate() Key: TS-2742 URL: https://issues.apache.org/jira/browse/TS-2742 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Labels: SPDY_ATS Attachments: 0001-TS-2742-FetchSM-can-accept-both-IPv4-and-IPv6-now.patch Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- 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 ] Yunkai Zhang updated TS-2750: - Attachment: (was: 0001-TS-2742-FetchSM-can-accept-both-IPv4-and-IPv6-now.patch) 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_ATS 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. 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] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2759) SPDY: replace TS API with internal API
Yunkai Zhang created TS-2759: Summary: SPDY: replace TS API with internal API Key: TS-2759 URL: https://issues.apache.org/jira/browse/TS-2759 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Yunkai Zhang -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2759) SPDY: replace TS API with internal API
[ https://issues.apache.org/jira/browse/TS-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2759: - Description: SPDY in core was migrated from Taobao SPDY plugin, so it use many TS API that should be replaced with internal API. SPDY: replace TS API with internal API -- Key: TS-2759 URL: https://issues.apache.org/jira/browse/TS-2759 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Yunkai Zhang SPDY in core was migrated from Taobao SPDY plugin, so it use many TS API that should be replaced with internal API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2760) Add TSFetchClientProtoStackSet/Get() API in experimental.h
Yunkai Zhang created TS-2760:
Summary: Add TSFetchClientProtoStackSet/Get() API in experimental.h
Key: TS-2760
URL: https://issues.apache.org/jira/browse/TS-2760
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Yunkai Zhang
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as flow:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSProtoType
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSProtoType TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2760) Add TSFetchClientProtoStackSet/Get() API in experimental.h
[
https://issues.apache.org/jira/browse/TS-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang reassigned TS-2760:
Assignee: Yunkai Zhang
Add TSFetchClientProtoStackSet/Get() API in experimental.h
--
Key: TS-2760
URL: https://issues.apache.org/jira/browse/TS-2760
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as flow:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSProtoType
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSProtoType TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2760) Add TSFetchClientProtoStackSet/Get() API in experimental.h
[
https://issues.apache.org/jira/browse/TS-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2760:
-
Issue Type: Improvement (was: Bug)
Add TSFetchClientProtoStackSet/Get() API in experimental.h
--
Key: TS-2760
URL: https://issues.apache.org/jira/browse/TS-2760
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as flow:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSProtoType
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSProtoType TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2760) Add TSFetchClientProtoStackSet/Get() API in experimental.h
[
https://issues.apache.org/jira/browse/TS-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2760:
-
Description:
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as below:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSProtoType
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSProtoType TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
was:
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as flow:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSProtoType
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSProtoType TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
Add TSFetchClientProtoStackSet/Get() API in experimental.h
--
Key: TS-2760
URL: https://issues.apache.org/jira/browse/TS-2760
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as below:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSProtoType
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSProtoType TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2760) Add TSFetchClientProtoStackSet/Get() API in experimental.h
[
https://issues.apache.org/jira/browse/TS-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2760:
-
Description:
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as below:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSClientProtoStack
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSClientProtoStack TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
was:
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as below:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm, TSProtoType
proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSProtoType TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
Add TSFetchClientProtoStackSet/Get() API in experimental.h
--
Key: TS-2760
URL: https://issues.apache.org/jira/browse/TS-2760
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as below:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm,
TSClientProtoStack proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSClientProtoStack TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2760) Add TSFetchClientProtoStackSet/Get() API in experimental.h
[
https://issues.apache.org/jira/browse/TS-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2760:
-
Attachment: 0002-TS-2760-Use-TSFetchClientProtoStackSet-API-in-SPDY.patch
0001-TS-2760-Add-TSFetchClientProtoStackSet-Get-API-in-ex.patch
Add TSFetchClientProtoStackSet/Get() API in experimental.h
--
Key: TS-2760
URL: https://issues.apache.org/jira/browse/TS-2760
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Attachments:
0001-TS-2760-Add-TSFetchClientProtoStackSet-Get-API-in-ex.patch,
0002-TS-2760-Use-TSFetchClientProtoStackSet-API-in-SPDY.patch
Users need a way to set/get client protocol stack when working with TSFetchSM
extended API, I'll add two API showed as below:
{code}
/*
* Set client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
* @param proto_stack: client protocol stack.
*/
tsapi void TSFetchClientProtoStackSet(TSFetchSM fetch_sm,
TSClientProtoStack proto_stack);
/*
* Get client protocol stack in FetchSM
*
* @param fetch_sm: returned value of TSFetchCreate().
*
* return the client protocol stack of fetch_sm.
*/
tsapi TSClientProtoStack TSFetchClientProtoStackGet(TSFetchSM fetch_sm);
{code}
SPDY in core need these API to add TS_PROTO_SPDY to the protocol stack, so
that logging module can record protocol stack correctly.
Actually, these two API had been implemented in Taobao's branch, I forgot to
migrate them to ATS core, all it's my wrong.
--
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 ] Yunkai Zhang updated TS-2743: - Fix Version/s: 5.0.0 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_ATS 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] [Commented] (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:comment-tabpanelfocusedCommentId=13982359#comment-13982359 ] Yunkai Zhang commented on TS-2743: -- For SpdyNV::SpdyNV(), what it does is to convert HTTP headers to *string* key-value pairs, it does not care the type of each header. Using TSMimeHdrFieldValueDateGet() here is bad! It will call mime_parse_date() to parse string, which will obviously waste CPU time. 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_ATS 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] [Commented] (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:comment-tabpanelfocusedCommentId=13982365#comment-13982365 ] Yunkai Zhang commented on TS-2743: -- my bet is on the ATS doing something wrong to mess up the memory. If that is true, I think we can continue get crashed after applying the newest patches, just waiting for it. Note: I have committed several patches about SPDY to master today. 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_ATS 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] [Commented] (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:comment-tabpanelfocusedCommentId=13982369#comment-13982369 ] Yunkai Zhang commented on TS-2743: -- To verify your bet, you can also add some code to make ATS generate core dump when the value of header is NULL. FYI. 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_ATS 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] [Comment Edited] (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:comment-tabpanelfocusedCommentId=13982369#comment-13982369
]
Yunkai Zhang edited comment on TS-2743 at 4/27/14 4:11 PM:
---
To verify your bet, you can also add some code to make ATS generate core dump
when the value of header is NULL.
For example:
{code}
if (!value || !value_len ) {
raise(SIGABRT);
}
{code}
FYI.
was (Author: yunkai):
To verify your bet, you can also add some code to make ATS generate core dump
when the value of header is NULL.
FYI.
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_ATS
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] [Commented] (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:comment-tabpanelfocusedCommentId=13982383#comment-13982383 ] Yunkai Zhang commented on TS-2743: -- Sorry, I forgot ink_release_assert() will generate core as well:) If you have got core, why not show more context of the core to us? With the core, by printing the whole HTTP headers, it should be easy to know whether the memory was messed up. 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_ATS 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] [Commented] (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:comment-tabpanelfocusedCommentId=13982032#comment-13982032
]
Yunkai Zhang commented on TS-2743:
--
[~sudheerv]:
I have tested SPDY with 'Expires' and 'Content-Type' headers, all is ok(to see
the SYN_REPLY frame showed as flow):
{code}
[root@test79 ~]# spdycat -3 -v --no-tls http://localhost/a.txt
[ 0.000] Handshake complete
...
[ 0.002] recv SYN_REPLY frame version=3, flags=0, length=153
(stream_id=1)
:status: 200 OK
:version: HTTP/1.1
accept-ranges: bytes
age: 1974
cache-control: max-age=86400
content-length: 14
content-type: text/plain
date: Sat, 26 Apr 2014 15:20:26 GMT
etag: 52bfa00f-e
expires: Sun, 27 Apr 2014 15:20:26 GMT
last-modified: Sun, 29 Dec 2013 04:07:43 GMT
server: ATS/5.0.0
Hello, World!
...
{code}
According rfc2616/rfc1123/rfc822:
{code}
The format is an absolute date and time as defined by HTTP-date in section
3.3.1; it MUST be in RFC 1123 date format:
Expires = Expires : HTTP-date
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: if a response includes a Cache-Control field with the max-
age directive (see section 14.9.3), that directive overrides the
Expires field.
{code}
IIUC, the value of 'Expires' header, as well as 'Content-Type', must be string
and can't be NULL.
It seems that your original server returns invalid value of 'Expires' and
'Content-Type' ?
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_ATS
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] [Commented] (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:comment-tabpanelfocusedCommentId=13982179#comment-13982179 ] Yunkai Zhang commented on TS-2743: -- All legal HTTP headers should be in string format, that is why we should use 'TSMimeHdrFieldValueStringGet' to extract value. The root cause of this issue is that SpdyNV does not check and ignore invalid HTTP headers carefully. What we should do is to check the return value of 'TSMimeHdrFieldValueStringGet' and ignore bad HTTP headers, instead of replacing a new method. I'll give a patch later, please test it. 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_ATS 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-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 ] Yunkai Zhang updated TS-2743: - Attachment: 0001-TS-2743-Ignore-invalid-HTTP-headers-in-SpdyNV-carefu.patch 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_ATS 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] [Commented] (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:comment-tabpanelfocusedCommentId=13982191#comment-13982191 ] Yunkai Zhang commented on TS-2743: -- I don't agree to use 'TSMimeHdrFieldValueDateGet'. I don't think replacing with internal API is urgent, we can use TS API to fix these problem firstly. After fixing all of these series issues, we can open a new jira ticket to replace TS API with internals. 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_ATS 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] [Assigned] (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 ] Yunkai Zhang reassigned TS-2750: Assignee: Yunkai Zhang 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_ATS 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. 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] -- 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 ] Yunkai Zhang updated TS-2750: - Attachment: 0001-TS-2742-FetchSM-can-accept-both-IPv4-and-IPv6-now.patch 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_ATS Attachments: 0001-TS-2742-FetchSM-can-accept-both-IPv4-and-IPv6-now.patch 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. 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] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13982195#comment-13982195 ] Yunkai Zhang commented on TS-2743: -- And it seems that TS-2750 may caused by the side-effect of TS-2743，so let's fix them one by one. 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_ATS 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)
Re: [jira] [Commented] (TS-2753) Add SPDY statistics
You can also use jira system to create your own filter with 'SPDY' keywork:) On Fri, Apr 25, 2014 at 10:42 PM, Sudheer Vinukonda (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981066#comment-13981066] Sudheer Vinukonda commented on TS-2753: --- Hi Wei Sun - Can you pls prepend the ticket synopsis with the tag SPDY_ATS (similar to TS-2740, 2742, 2743, 2750 etc) to be able to group the tickets easily? Thanks! Add SPDY statistics --- Key: TS-2753 URL: https://issues.apache.org/jira/browse/TS-2753 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Wei Sun Adding stats to spdy helps monitoring and troubleshooting, it would be good to define and add the general information like the HTTP stats in proxy/http/HttpConfig.h and spdy specific stats as well. -- This message was sent by Atlassian JIRA (v6.2#6252) -- Yunkai Zhang Work at Taobao
Re: [jira] [Commented] (TS-2729) Add HTTP/2 support to ATS
@James,
I'm not working on ATS project at Taobao now, and be busy with another
project.
I hope you and other developers can continue to improve SPDY/HTTP2.
The probe mechanism and configuration will be easy to refined, patch is
welcome.
Moving from TS API to the internal API(IIUC, that is removing the
dependency of FetchSM) needs more hard work，and I don't think it's more
urgent than introducing HTTP/2 to ATS.
I believe that the supporting of HTTP/2 will make ATS grab much more market
share, that is really very important for this community.
So, I hope our community can go on to refine SPDY/HTTP2 patches, so that it
can be landed as much as quickly.
On Thu, Apr 24, 2014 at 12:47 PM, James Peach (JIRA) j...@apache.orgwrote:
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979277#comment-13979277]
James Peach commented on TS-2729:
-
I started taking a closer look at this, and I can see that you have
followed the example of SPDY. Unfortunately, SPDY is currently a bad
example; it still needs significant amounts of work to move from the TS API
on to the internal API; the protocol probe mechanism needs work; the
configuration needs work. There's no tests for any of this. Sorry, but I'd
rather not merge this in it's current state.
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, http2-0001.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)
--
Yunkai Zhang
Work at Taobao
[jira] [Commented] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979425#comment-13979425
]
Yunkai Zhang commented on TS-2729:
--
@James,
I'm not working on ATS project at Taobao now, and be busy with another project.
I hope you and other developers can continue to improve SPDY/HTTP2.
The probe mechanism and configuration will be easy to refined, patch is welcome.
Moving from TS API to the internal API(IIUC, that is removing the dependency of
FetchSM) needs more hard work，and I don't think it's more urgent than
introducing HTTP/2 to ATS.
I believe that the supporting of HTTP/2 will make ATS grab much more market
share, that is really very important for this community.
So, I hope our community can go on to refine SPDY/HTTP2 patches, so that it can
be landed as much as quickly.
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, http2-0001.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-2743) SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
[ https://issues.apache.org/jira/browse/TS-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979435#comment-13979435 ] Yunkai Zhang commented on TS-2743: -- I will try to fix it, maybe at this weekend. Thanks for your report. 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 Reporter: Sudheer Vinukonda 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-2743) SPDY_ATS - 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 ] Yunkai Zhang updated TS-2743: - Assignee: Yunkai Zhang 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 Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang 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] [Commented] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979448#comment-13979448
]
Yunkai Zhang commented on TS-2729:
--
I think I misunderstand [~jamespeach] about TS API to internal API.
Yes, SPDY use a lot of TS API which could be replaced by their internal form.
But, I do like TS API form, they are easy to use and more readable.
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, http2-0001.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-2742) SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate()
[ https://issues.apache.org/jira/browse/TS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979818#comment-13979818 ] Yunkai Zhang commented on TS-2742: -- It's seems that 'ats_is_ip4(client_addr)' assert is obsoleted. But I didn't test it with IPv6 when I developed SPDY patches. Could you remove this assert to see if it would be fixed? SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate() --- Key: TS-2742 URL: https://issues.apache.org/jira/browse/TS-2742 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2742) SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate()
[ https://issues.apache.org/jira/browse/TS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979818#comment-13979818 ] Yunkai Zhang edited comment on TS-2742 at 4/24/14 3:09 PM: --- It seems that 'ats_is_ip4(client_addr)' assert is obsoleted. But I didn't test it with IPv6 when I developed SPDY patches. Could you remove this assert to see if it could be fixed? Please give us feedback after testing. was (Author: yunkai): It's seems that 'ats_is_ip4(client_addr)' assert is obsoleted. But I didn't test it with IPv6 when I developed SPDY patches. Could you remove this assert to see if it would be fixed? SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate() --- Key: TS-2742 URL: https://issues.apache.org/jira/browse/TS-2742 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2742) SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate()
[ https://issues.apache.org/jira/browse/TS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979826#comment-13979826 ] Yunkai Zhang commented on TS-2742: -- Nice. SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate() --- Key: TS-2742 URL: https://issues.apache.org/jira/browse/TS-2742 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2750) SPDY_ATS - Crash with SPDY on production environment in HttpAcceptCont::mainEvent
[ https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980647#comment-13980647 ] Yunkai Zhang commented on TS-2750: -- thanks for your input. 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 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. 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] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974007#comment-13974007
]
Yunkai Zhang commented on TS-2729:
--
Cool!
Please go on to finish the TODO list(providing separated patches will be
welcome), I'm pleasure to give any help if you need.
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
Reporter: Ryo OKUBO
Attachments: http2-0001.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 only NPN 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-11 and later.
* Support ALPN.
* Add settings related to HTTP/2 into records.config.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946133#comment-13946133
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 2:26 PM:
---
Hi [~sudheerv], [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fields(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new field-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
%WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this field-function, it's will be more efficient -- it will be only
executed on certain fields.
was (Author: yunkai):
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
%WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946659#comment-13946659 ] Yunkai Zhang commented on TS-2636: -- Hi [~sudheerv]: With LogFilter, the code needs to compare all fields in LogFormat: 1) to check if the field satisfy the Condition = xxx, 2) if Yes, to do WIPE. It'll slow down each HTTP response, especially when the number of filters become larger. But with field-function, the WIPE action will only affect certain fields that surrounding with %WIPE(...) function in LogFormat. I can image that to implement a field-function would be more easier than adding a new filter-action(with few codes), so don't worry, just try it:) I'm pleasure to give you help if you need. Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946607#comment-13946607
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 2:32 PM:
---
How about SHADOW? In Linux, {{/etc/shadow}} is well known file used to contain
encrypted user account:)
was (Author: yunkai):
How about SHADOW? In Linux, {{shadow}} is well known command used to encrypt
password:)
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946607#comment-13946607
]
Yunkai Zhang commented on TS-2636:
--
How about SHADOW? In Linux, {{shadow}} is well known command used to encrypt
password:)
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944797#comment-13944797 ] Yunkai Zhang commented on TS-2636: -- [~sudheerv]: Which ATS version does your patch based on? There is no *proxy/http/logging/* directory now, LogField.h is in *proxy/logging/* directory. Can you rebase your patch on ATS master branch? So that I can easy to review it. Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945404#comment-13945404
]
Yunkai Zhang commented on TS-2636:
--
I like the idea of this patch, it would be helpful to protect user's privacy.
Here are my some advises:
1) There are some coding style problems, such as invalid tailling space, please
read ATS coding style:
https://cwiki.apache.org/confluence/display/TS/Coding+Style
2) write_this_entry() and toss_this_entry() share most common codes, we should
squash them. The same to __checkCondition() and _checkConditionAndWipe().
3) It seems that wipeField() only wipe URL parameters, renaming it to
wipeUrlParam() or other similar name would be better. Similarly, WIPE action
seems too general for this purpose, how about renaming it to WIPE_URL_PARAM?
4) Please don't forget to add some description in documents:
{{logs_xml.config.default}} and {{logs_xml.config.en.rst}}
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946133#comment-13946133
]
Yunkai Zhang commented on TS-2636:
--
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(filed, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946133#comment-13946133
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 4:02 AM:
---
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
%WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
was (Author: yunkai):
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946133#comment-13946133
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 4:01 AM:
---
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(field, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
was (Author: yunkai):
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since WIPE action only applys URL fileds(eg. %cquuc), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%WIPE(filed, param1, param2, ...)}}
{code}
%WIPE(cquuc, token) // WIPE token parameter
#WIPE(cquuc, token, userid, ...) // WIPE token/userid/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
Enhance ATS custom logging to support WIPE filter action
Key: TS-2636
URL: https://issues.apache.org/jira/browse/TS-2636
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Sudheer Vinukonda
Assignee: Yunkai Zhang
Labels: Review
Fix For: 5.0.0
Attachments: ts2636.diff
Currently, ATS custom logging supports LogFilters with actions Accept,
Reject. This feature request is to add a new filter action WIPE. WIPE can
be used in hiding sensitive parameters (e.g. userid, password) within the
query part of a URL. Attached is a draft version of the patch. Kindly review
and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0001-TS-2431-Preparation-of-SPDY-protocol.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0005-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0003-TS-2431-Extends-and-optimizes-FetchSM.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0004-TS-2431-Implement-dechunk-supporting-in-FetchSM.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0002-TS-2431-Add-autoconf-options-for-SPDY.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0006-TS-2431-Add-SSL-supporting-for-SPDY.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0007-TS-2431-Set-proto_type-properly-for-HttpSM.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0008-TS-2431-Add-client_req_proto_type-cqpt-field-into-lo.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch
0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0013-TS-2431-Set-eof-flag-to-prevent-spdy-client-hang.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0011-TS-2431-Fix-dechunking-on-FetchSM-s-response-data.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0012-TS-2431-Set-the-water-mark-of-resp_buffer-with-INT64.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0009-TS-2431-Close-SPDY-request-when-SPDY-is-not-endabled.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0010-TS-2431-Fix-infinite-loop-when-reading-the-fist-byte.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0014-TS-2431-Ignore-fetch-errors-after-FETCH_BODY_DONE.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13936267#comment-13936267 ] Yunkai Zhang commented on TS-2636: -- OK, I'll review it after this weekend:) Enhance ATS custom logging to support WIPE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2630) Add lib/ts/apidefs.h to place common types
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2630: - Attachment: (was: 0001-TS-2630-Add-ts-types.h-to-place-common-types.patch) Add lib/ts/apidefs.h to place common types -- Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 The apidefs.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in api/ts/ts.h should be migrated to lib/ts/apidefs.h, so this patch is just a beginning ... Why I named it 'apidefs.h' instead of 'defs.h' and put it into 'lib/ts'? 1) Firstly, there is a 'ink_defs.h' file in 'lib/ts', then 'defs.h' seems too similar with it. So named it 'apidefs.h' would be more clearly. 2) Since 'apidefs.h' will be shared not only by 'iocore' modules, puting it into 'lib/ts' would be more suitable than 'iocore/api' or any other else. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2630) Add ts/types.h to place common types shared between API and core
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2630: - Description: The apidefs.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in api/ts/ts.h should be migrated to lib/ts/apidefs.h, so this patch is just a beginning ... Why I named it 'apidefs.h' instead of 'defs.h' and put it into 'lib/ts'? 1) Firstly, there is a 'ink_defs.h' file in 'lib/ts', then 'defs.h' seems too similar with it. So named it 'apidefs.h' would be more clearly. 2) Since 'apidefs.h' will be shared not only by 'iocore' modules, puting it into 'lib/ts' would be more suitable than 'iocore/api' or any other else. was: ts/types.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in ts/ts.h should be migrated to ts/types.h, so this patch is just a beginning ... Add ts/types.h to place common types shared between API and core Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 The apidefs.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in api/ts/ts.h should be migrated to lib/ts/apidefs.h, so this patch is just a beginning ... Why I named it 'apidefs.h' instead of 'defs.h' and put it into 'lib/ts'? 1) Firstly, there is a 'ink_defs.h' file in 'lib/ts', then 'defs.h' seems too similar with it. So named it 'apidefs.h' would be more clearly. 2) Since 'apidefs.h' will be shared not only by 'iocore' modules, puting it into 'lib/ts' would be more suitable than 'iocore/api' or any other else. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2630) Add lib/ts/apidefs.h to place common types
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2630: - Summary: Add lib/ts/apidefs.h to place common types (was: Add ts/types.h to place common types shared between API and core) Add lib/ts/apidefs.h to place common types -- Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 The apidefs.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in api/ts/ts.h should be migrated to lib/ts/apidefs.h, so this patch is just a beginning ... Why I named it 'apidefs.h' instead of 'defs.h' and put it into 'lib/ts'? 1) Firstly, there is a 'ink_defs.h' file in 'lib/ts', then 'defs.h' seems too similar with it. So named it 'apidefs.h' would be more clearly. 2) Since 'apidefs.h' will be shared not only by 'iocore' modules, puting it into 'lib/ts' would be more suitable than 'iocore/api' or any other else. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2630) Add lib/ts/apidefs.h to place common types
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2630: - Attachment: 0001-TS-2630-Add-lib-ts-apidefs.h-to-place-common-types.patch Add lib/ts/apidefs.h to place common types -- Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 Attachments: 0001-TS-2630-Add-lib-ts-apidefs.h-to-place-common-types.patch The apidefs.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in api/ts/ts.h should be migrated to lib/ts/apidefs.h, so this patch is just a beginning ... Why I named it 'apidefs.h' instead of 'defs.h' and put it into 'lib/ts'? 1) Firstly, there is a 'ink_defs.h' file in 'lib/ts', then 'defs.h' seems too similar with it. So named it 'apidefs.h' would be more clearly. 2) Since 'apidefs.h' will be shared not only by 'iocore' modules, puting it into 'lib/ts' would be more suitable than 'iocore/api' or any other else. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2630) Create ts/types.h used to place types shared between API and core
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2630: - Fix Version/s: 5.0.0 Create ts/types.h used to place types shared between API and core - Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2630) Create ts/types.h used to place types shared between API and core
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang reassigned TS-2630: Assignee: Yunkai Zhang Create ts/types.h used to place types shared between API and core - Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2630) Create ts/types.h used to place types shared between API and core
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2630: - Description: ts/types.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in ts/ts.h should be migrated to ts/types.h, so this patch is just a beginning ... Create ts/types.h used to place types shared between API and core - Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 ts/types.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in ts/ts.h should be migrated to ts/types.h, so this patch is just a beginning ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2630) Add ts/types.h to place common types shared between API and core
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2630: - Summary: Add ts/types.h to place common types shared between API and core (was: Create ts/types.h used to place types shared between API and core) Add ts/types.h to place common types shared between API and core Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 Attachments: 0001-TS-2630-Add-ts-types.h-to-place-common-types.patch ts/types.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in ts/ts.h should be migrated to ts/types.h, so this patch is just a beginning ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2630) Add ts/types.h to place common types shared between API and core
[ https://issues.apache.org/jira/browse/TS-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931926#comment-13931926 ] Yunkai Zhang commented on TS-2630: -- agree, I'll update it later. Add ts/types.h to place common types shared between API and core Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang Assignee: Yunkai Zhang Fix For: 5.0.0 Attachments: 0001-TS-2630-Add-ts-types.h-to-place-common-types.patch ts/types.h file is used to place common types that can be shared between internal code and TS APIs. It's hard to judge what types in ts/ts.h should be migrated to ts/types.h, so this patch is just a beginning ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2610) Add client_protocol_stack, %cps field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2610:
-
Attachment: (was:
0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch)
Add client_protocol_stack, %cps field into LogFormat
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: review
Fix For: 5.0.0
This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
TS-2612.
Add client_protocol_stack(%cps) field into LogFormat.
The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
The output of %cps field would be the conjunction of protocol names in
client protocol stack spliced with '+', such as
{code}
HTTP // TCP is the defualt transport protocol, would be omitted
by default.
TLS+SPDY
TLS+HTTP
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: (was:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch)
Introduce TSHttpConnectWithProtoStack() API
---
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
would be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
Introduce TSHttpConnectWithProtoStack() API
---
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
Attachments:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
would be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add client_protocol_stack, %cps field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2610:
-
Attachment: 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
Add client_protocol_stack, %cps field into LogFormat
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: review
Fix For: 5.0.0
Attachments:
0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
TS-2612.
Add client_protocol_stack(%cps) field into LogFormat.
The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
The output of %cps field would be the conjunction of protocol names in
client protocol stack spliced with '+', such as
{code}
HTTP // TCP is the defualt transport protocol, would be omitted
by default.
TLS+SPDY
TLS+HTTP
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: (was:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch)
Introduce TSHttpConnectWithProtoStack() API
---
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
Attachments:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
would be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
Introduce TSHttpConnectWithProtoStack() API
---
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
Attachments:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
would be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
Introduce TSHttpConnectWithProtoStack() API
---
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
Attachments:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
would be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add client_protocol_stack, %cps field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2610:
-
Attachment: (was:
0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch)
Add client_protocol_stack, %cps field into LogFormat
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: review
Fix For: 5.0.0
Attachments:
0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
TS-2612.
Add client_protocol_stack(%cps) field into LogFormat.
The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
The output of %cps field would be the conjunction of protocol names in
client protocol stack spliced with '+', such as
{code}
HTTP // TCP is the defualt transport protocol, would be omitted
by default.
TLS+SPDY
TLS+HTTP
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931325#comment-13931325
]
Yunkai Zhang commented on TS-2612:
--
Let's land it, so that I can move forward to SPDY patches.
Introduce TSHttpConnectWithProtoStack() API
---
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
Attachments:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API and
relatived tyeps:
{code}
/**
TSClientProtoStack represents what protocols are used by
the client. It may be composed by several TSProtoType.
The value of TSProtoType indicates bit-offset that can
be mapped to TSClientProtoStack by bit shifting.
For example, TLS+SPDY can be mapped to protocol stack:
proto_stack = (1u TS_PROTO_TLS) | (1u TS_PROTO_SPDY)
For the sake of brevity, TS_PROTO_TCP is usually omitted in
protocol stack.
*/
typedef enum {
/* Transport protocols (0~11) */
TS_PROTO_UDP = 0,
TS_PROTO_TCP = 1,
TS_PROTO_TLS = 2, /* TLS/SSL */
/* Application protocols (12~31) */
TS_PROTO_HTTP = 12,
TS_PROTO_SPDY = 13,
TS_PROTO_RTMP = 14,
TS_PROTO_WBSK = 15, /* WebSocket */
} TSProtoType;
typedef uint32_t TSClientProtoStack;
tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
would be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, (1u TS_PROTO_HTTP));
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
