[jira] [Assigned] (TS-1103) Traffic Server ESI plugin issues
[ https://issues.apache.org/jira/browse/TS-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-1103: - Assignee: Zhao Yongming > Traffic Server ESI plugin issues > > > Key: TS-1103 > URL: https://issues.apache.org/jira/browse/TS-1103 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: sometime > Environment: Newest trunk. >Reporter: Kevin Fox >Assignee: Zhao Yongming > Fix For: 3.1.4 > > Attachments: esi.patch, gzip.patch > > > Patch to fix: > * Makefile fix to add missing files. > * Change return code checking to match whats trunk trafficserver. > * Include missing header files. > * Fix c++ namespace issues. > * Work around strange name mangling/linking issue. > * Force the assumption that the cached data is RAW_ESI, not PACKED_ESI. > Things wouldn't work without it. > * Comment out a block of code that looked to be incorrectly handling > EOF. > After this, simply loading the plugin and setting response header X-ESI > in apache httpd seems to work. > A few further bugs I have bumped into that aren't addressed in this > patch: > * It doesn't seem to parse gzip like it looks like it should. To work > around, I had to disable it in apache httpd with "RewriteRule . - > [E=no-gzip:1]" > * If the client requests gzip, the ESI processor will gzip the result. > It works in firefox but is invalid in chrome. Pulling a dump with curl > and running it through gzip --list shows it has the correct uncompressed > size and compressed size. using zcat shows the correct data but has the > warning: "invalid compressed data--length error". As far as I read the > gzip spec though, the raw binary file looks valid to me. Not sure what > this is. This can probably be simply disabled for now though. > * esi:include is slightly broken. You get all the data back properly but > sometimes the headers are sent prematurely with a Content-Length of > 2**31-1. This causes clients to timeout and fail. I'm currently unsure > how to fix this. > I've tried a few of the more advanced esi features, including ensuring > cookies make it back to the origin server and things seem to work good. > So, once the above bugs are figured out (particularly the include one), > I think it will be in pretty good shape. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1171) Crash report: http_ui cache lookup, double free
[ https://issues.apache.org/jira/browse/TS-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming resolved TS-1171. --- Resolution: Fixed Fix Version/s: 3.1.4 Assignee: Zhao Yongming in 1abf9bc6179b6e0ccb851c334da1d81bc65cccbc > Crash report: http_ui cache lookup, double free > --- > > Key: TS-1171 > URL: https://issues.apache.org/jira/browse/TS-1171 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.4 >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.1.4 > > > {code} > *** glibc detected *** /opt/ats/bin/traffic_server: double free or corruption > (!prev): 0x013e9a50 *** > === Backtrace: = > /lib64/libc.so.6(+0x77856)[0x2b14ef973856] > /lib64/libc.so.6(cfree+0x6c)[0x2b14ef97774c] > /opt/ats/bin/traffic_server(ShowCache::~ShowCache()+0x20)[0x6428c0] > /opt/ats/bin/traffic_server(ShowCont::done(int, int, void*)+0x23)[0x5e1c63] > /opt/ats/bin/traffic_server(ShowCache::handleCacheEvent(int, > Event*)+0x15d7)[0x641ee7] > /opt/ats/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, > CacheFragType, char*, int)+0x42c)[0x64e62c] > /opt/ats/bin/traffic_server(ShowCache::lookup_url(int, > Event*)+0x1a5)[0x63f655] > /opt/ats/bin/traffic_server(EThread::process_event(Event*, > int)+0x90)[0x6a6350] > /opt/ats/bin/traffic_server(EThread::execute()+0x31b)[0x6a6c3b] > /opt/ats/bin/traffic_server[0x6a5142] > /lib64/libpthread.so.0(+0x8e2c)[0x2b14ed0f5e2c] > /lib64/libc.so.6(clone+0x6d)[0x2b14ef9d63cd] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1172) Remove remap/StringHash.{cc,h}
Remove remap/StringHash.{cc,h} -- Key: TS-1172 URL: https://issues.apache.org/jira/browse/TS-1172 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 These files are not used, nuke. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1172) Remove remap/StringHash.{cc,h}
[ https://issues.apache.org/jira/browse/TS-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1172. --- Resolution: Fixed > Remove remap/StringHash.{cc,h} > -- > > Key: TS-1172 > URL: https://issues.apache.org/jira/browse/TS-1172 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.4 > > > These files are not used, nuke. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1079: - Assignee: Leif Hedstrom > Add an API function to turn debugging on for specific transactions/sessions > --- > > Key: TS-1079 > URL: https://issues.apache.org/jira/browse/TS-1079 > Project: Traffic Server > Issue Type: Improvement > Components: Core, HTTP >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.4 > > Attachments: debug_specific.patch, debug_specific_2.patch, > debug_specific_3.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > When attempting to troubleshoot issues on a production ATS system, it > is often impossible/difficult to turn on any of the 'high-volume' debug tags > like http due to the performance impact. > > This enhancement allows a plugin to set a debug flag for a specific txn/ssn, > and replaces some of the internal Debug calls with a new function that checks > if the flag is turned on, and outputs the debug line regardless of the tag if > it is (The diags enable/disable flag is still taken into account). > The API will also have TSDebugSpecific in order to allow plugins to use the > same functionality. > In addition, we might consider adding an internal config file (remap-like) to > allow turning this flag on without plugin intervention. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241886#comment-13241886 ] Leif Hedstrom commented on TS-1079: --- Is the last patch missing a ts/ts.h.in change set? Also, what are the expectations on performance here? > Add an API function to turn debugging on for specific transactions/sessions > --- > > Key: TS-1079 > URL: https://issues.apache.org/jira/browse/TS-1079 > Project: Traffic Server > Issue Type: Improvement > Components: Core, HTTP >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.4 > > Attachments: debug_specific.patch, debug_specific_2.patch, > debug_specific_3.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > When attempting to troubleshoot issues on a production ATS system, it > is often impossible/difficult to turn on any of the 'high-volume' debug tags > like http due to the performance impact. > > This enhancement allows a plugin to set a debug flag for a specific txn/ssn, > and replaces some of the internal Debug calls with a new function that checks > if the flag is turned on, and outputs the debug line regardless of the tag if > it is (The diags enable/disable flag is still taken into account). > The API will also have TSDebugSpecific in order to allow plugins to use the > same functionality. > In addition, we might consider adding an internal config file (remap-like) to > allow turning this flag on without plugin intervention. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241974#comment-13241974 ] Leif Hedstrom commented on TS-1079: --- Fwiw, I measure about 4% slowdown or so. > Add an API function to turn debugging on for specific transactions/sessions > --- > > Key: TS-1079 > URL: https://issues.apache.org/jira/browse/TS-1079 > Project: Traffic Server > Issue Type: Improvement > Components: Core, HTTP >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.4 > > Attachments: debug_specific.patch, debug_specific_2.patch, > debug_specific_3.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > When attempting to troubleshoot issues on a production ATS system, it > is often impossible/difficult to turn on any of the 'high-volume' debug tags > like http due to the performance impact. > > This enhancement allows a plugin to set a debug flag for a specific txn/ssn, > and replaces some of the internal Debug calls with a new function that checks > if the flag is turned on, and outputs the debug line regardless of the tag if > it is (The diags enable/disable flag is still taken into account). > The API will also have TSDebugSpecific in order to allow plugins to use the > same functionality. > In addition, we might consider adding an internal config file (remap-like) to > allow turning this flag on without plugin intervention. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1078) trafficserver-3.1.1-unstable.tar.bz2 core dumps during load test
[ https://issues.apache.org/jira/browse/TS-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1078. --- Resolution: Duplicate Fix Version/s: (was: 3.1.4) Marking as duplicate for now, please reopen if it still happens on trunk. > trafficserver-3.1.1-unstable.tar.bz2 core dumps during load test > > > Key: TS-1078 > URL: https://issues.apache.org/jira/browse/TS-1078 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.1.1 > Environment: Redhat linux with no plugins (although stack trace shows > our plugin being called). The tests were run with no plugin and exactly the > same stack trace occurred. >Reporter: Alistair Stevenson >Assignee: weijin >Priority: Blocker > > {code} > (gdb) bt > #0 ink_restore_signal_handler_frame (stack=0x7f2a67650490, len= optimized out>, signalhandler_frame=2) at ink_stack_trace.cc:68 > #1 ink_stack_trace_get (stack=0x7f2a67650490, len=, > signalhandler_frame=2) at ink_stack_trace.cc:89 > #2 0x7f2a682dcf7d in ink_stack_trace_dump (sighandler_frame=2) at > ink_stack_trace.cc:114 > #3 0x004d2512 in signal_handler (sig=11) at signals.cc:222 > #4 > #5 ink_atomiclist_push (l=0x100bb0, item=0x72a9100) at ink_queue.cc:457 > #6 0x0065800b in ProtectedQueue::enqueue (this=0x100bb0, e= optimized out>, fast_signal=false) at ProtectedQueue.cc:53 > #7 0x0062c3ca in NetVConnection::Handle::do_locked_io_close > (this=0x6e01830, lerrno=-1) at NetVConnection.cc:93 > #8 0x00507608 in HttpServerSession::do_io_close (this=0x6e01770, > alerrno=) at HttpServerSession.cc:122 > #9 0x0050a78b in HttpSessionManager::acquire_session (this=0x941940, > cont=, ip=0xa5443c0, hostname=0x5732c19 > "10.20.48.15", ua_session=, sm=0xa543d20) > at HttpSessionManager.cc:257 > #10 0x0051d544 in HttpSM::do_http_server_open (this=0xa543d20, > raw=false) at HttpSM.cc:4139 > #11 0x0051e0e8 in HttpSM::set_next_state (this=0xa543d20) at > HttpSM.cc:6464 > #12 0x0050b8ff in HttpSM::call_transact_and_set_next_state > (this=0xa543d20, f=) at HttpSM.cc:6319 > #13 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20, > event=6, data=0x0) at HttpSM.cc:1446 > #14 0x00518499 in HttpSM::state_api_callback (this=0xa543d20, > event=6, data=0x0) at HttpSM.cc:1265 > #15 0x004a9af8 in TSHttpTxnReenable (txnp=, > event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407 > #16 0x7f2a63a3d45b in opwvPluginHandler (contp=0x7631780, > event=TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE, edata=0xa543d20) at > /bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi > c_server/plugin.cpp:82 > #17 0x00516585 in HttpSM::state_api_callout (this=0xa543d20, > event=, data=) at > HttpSM.cc:1372 > #18 0x0051de1a in HttpSM::set_next_state (this=0xa543d20) at > HttpSM.cc:6353 > #19 0x0050b8ff in HttpSM::call_transact_and_set_next_state > (this=0xa543d20, f=) at HttpSM.cc:6319 > #20 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20, > event=6, data=0x0) at HttpSM.cc:1446 > #21 0x00518499 in HttpSM::state_api_callback (this=0xa543d20, > event=6, data=0x0) at HttpSM.cc:1265 > #22 0x004a9af8 in TSHttpTxnReenable (txnp=, > event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407 > #23 0x7f2a63a3d6cc in opwvPluginHandler (contp=0x7631780, > event=TS_EVENT_HTTP_OS_DNS, edata=0xa543d20) at > /bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi > c_server/plugin.cpp:117 > #24 0x00516585 in HttpSM::state_api_callout (this=0xa543d20, > event=, data=) at > HttpSM.cc:1372 > #25 0x0051de1a in HttpSM::set_next_state (this=0xa543d20) at > HttpSM.cc:6353 > #26 0x0050b8ff in HttpSM::call_transact_and_set_next_state > (this=0xa543d20, f=) at HttpSM.cc:6319 > #27 0x0050d58a in HttpSM::do_hostdb_lookup (this=0xa543d20) at > HttpSM.cc:3749 > #28 0x0051e72b in HttpSM::set_next_state (this=0xa543d20) at > HttpSM.cc:6414 > #29 0x0050b8ff in HttpSM::call_transact_and_set_next_state > (this=0xa543d20, f=) at HttpSM.cc:6319 > #30 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20, > event=6, data=0x0) at HttpSM.cc:1446 > #31 0x00518499 in HttpSM::state_api_callback (this=0xa543d20, > event=6, data=0x0) at HttpSM.cc:1265 > #32 0x004a9af8 in TSHttpTxnReenable (txnp=, > event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407 > #33 0x7f2a63a3d4eb in opwvPluginHandler (contp=0x7631780, > event=TS_EVENT_HTTP_POST_REMAP, edata=0xa543d20) at > /bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi > c_server/plugin.cpp:90 > #34 0x00516585 in HttpSM::state_api_ca
[jira] [Updated] (TS-981) Remove libev support (it's not well support, and might crash)
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-981: - Summary: Remove libev support (it's not well support, and might crash) (was: ATS as transparent proxy crashes under heavy load) Changing the summary on this one, as we'll remove libev support (I checked with John on this). > Remove libev support (it's not well support, and might crash) > - > > Key: TS-981 > URL: https://issues.apache.org/jira/browse/TS-981 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.0 > Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled > with TPROXY support. > ATS compiled as: ./configure --enable-tproxy --enable-libev >Reporter: Danny Shporer >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.1.4 > > Attachments: records.config > > > ATS crashes under heavy load testing - around 25,000 HTTP transactions per > second. > I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. > GDB info: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x42174940 (LWP 6663)] > 0x0068fd4b in modify (this=0x2b12c628, event= out>, e=) at P_UnixNet.h:536 > 536 fd_change(event_loop->eio, eio.fd, 0); > (gdb) bt > #0 0x0068fd4b in modify (this=0x2b12c628, event= out>, e=) at P_UnixNet.h:536 > #1 NetHandler::mainNetEvent (this=0x2b12c628, event= out>, e=) at UnixNet.cc:432 > #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, > e=0xf44570, calling_code=5) at I_Continuation.h:146 > #3 0x006c055c in EThread::execute (this=0x2b12b010) at > UnixEThread.cc:262 > #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 > #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 > #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 > (gdb) info f > Stack level 0, frame at 0x42174030: > rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f > inlined into frame 1 > source language c++. > Arglist at unknown address. > Locals at unknown address, Previous frame's sp in rsp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-981) Remove libev support (it's not well support, and might crash)
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-981. -- Resolution: Fixed > Remove libev support (it's not well support, and might crash) > - > > Key: TS-981 > URL: https://issues.apache.org/jira/browse/TS-981 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.0 > Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled > with TPROXY support. > ATS compiled as: ./configure --enable-tproxy --enable-libev >Reporter: Danny Shporer >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.1.4 > > Attachments: records.config > > > ATS crashes under heavy load testing - around 25,000 HTTP transactions per > second. > I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. > GDB info: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x42174940 (LWP 6663)] > 0x0068fd4b in modify (this=0x2b12c628, event= out>, e=) at P_UnixNet.h:536 > 536 fd_change(event_loop->eio, eio.fd, 0); > (gdb) bt > #0 0x0068fd4b in modify (this=0x2b12c628, event= out>, e=) at P_UnixNet.h:536 > #1 NetHandler::mainNetEvent (this=0x2b12c628, event= out>, e=) at UnixNet.cc:432 > #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, > e=0xf44570, calling_code=5) at I_Continuation.h:146 > #3 0x006c055c in EThread::execute (this=0x2b12b010) at > UnixEThread.cc:262 > #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 > #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 > #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 > (gdb) info f > Stack level 0, frame at 0x42174030: > rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f > inlined into frame 1 > source language c++. > Arglist at unknown address. > Locals at unknown address, Previous frame's sp in rsp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira