[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
