[jira] [Created] (TS-1173) remap.config comments are wrong
remap.config comments are wrong --- Key: TS-1173 URL: https://issues.apache.org/jira/browse/TS-1173 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Leif Hedstrom Priority: Minor Fix For: 3.3.0 The comments in remap.config describe the configuration lines incorrectly. -- 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-1173) remap.config comments are wrong
[ https://issues.apache.org/jira/browse/TS-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1173. --- Resolution: Fixed Fix Version/s: (was: 3.3.0) 3.1.4 > remap.config comments are wrong > --- > > Key: TS-1173 > URL: https://issues.apache.org/jira/browse/TS-1173 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Affects Versions: 3.1.3 >Reporter: Alan M. Carroll >Assignee: Leif Hedstrom >Priority: Minor > Labels: remap > Fix For: 3.1.4 > > > The comments in remap.config describe the configuration lines incorrectly. -- 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-1092) Remove server mode SSL termination.
[ https://issues.apache.org/jira/browse/TS-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1092. --- Resolution: Fixed > Remove server mode SSL termination. > --- > > Key: TS-1092 > URL: https://issues.apache.org/jira/browse/TS-1092 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Affects Versions: 3.1.1 >Reporter: Alan M. Carroll >Assignee: Leif Hedstrom >Priority: Minor > Labels: cleanup, ssl > Fix For: 3.1.4 > > > Checks are done in the SSL configuration to check for "server mode" > termination. As far as I can tell it is never actually used anywhere, nor is > it documented. -- 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-1036) Improve squid log compatibility
[ https://issues.apache.org/jira/browse/TS-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1036. --- Resolution: Fixed > Improve squid log compatibility > > > Key: TS-1036 > URL: https://issues.apache.org/jira/browse/TS-1036 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.4 > > > See > https://github.com/mnot/squidpeek/commit/3874cb902f257974d16c8eae5fc5a77c6fafbf69 > for some "differences", from mnot as well: > all of the ERR_* ones > squid does TCP_REFRESH_FAIL_HIT, you do TCP_REF_FAIL_HIT > squid does TCP_CLIENT_REFRESH_MISS, you do TCP_CLIENT_REFRESH > squid does TCP_SWAPFAIL_MISS, you do TCP_SWAPFAIL -- 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-1174) Should we eliminate all ERR_* "status" message in squid logging?
Should we eliminate all ERR_* "status" message in squid logging? Key: TS-1174 URL: https://issues.apache.org/jira/browse/TS-1174 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Fix For: 3.3.0 In more recent versions of Squid, ERR_* status messages have been merged into the status code. E.g. {code} ERR_* Errors are now contained in the status code. {code} Should we do likewise? -- 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] [Updated] (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 ] Uri Shachar updated TS-1079: Attachment: debug_specific_4.patch This time including the ts.h.in changes... > 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, debug_specific_4.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=13242822#comment-13242822 ] Uri Shachar commented on TS-1079: - I've retested the perf a couple of times -- can't see any significant change (Tested with debug enabled and disabled). > 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, debug_specific_4.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] [Created] (TS-1175) The LogBuffer object is allocated with new (and deallocated with delete)
The LogBuffer object is allocated with new (and deallocated with delete) Key: TS-1175 URL: https://issues.apache.org/jira/browse/TS-1175 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Fix For: 3.3.0 We should at least use a class allocator for LogBuffer itself, and perhaps even its internal buffer. -- 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-1176) Eliminate the delayed delete of LogBuffer
Eliminate the delayed delete of LogBuffer - Key: TS-1176 URL: https://issues.apache.org/jira/browse/TS-1176 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 There's a race condition in another place in the code, and it's obvious to me that this deferred delete was done to avoid this race condition. -- 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-801) Crash Report: enable update will triger Segmentation fault
[ https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242983#comment-13242983 ] Zhao Yongming commented on TS-801: -- I think in the update, the UA is cleared from the SM but what is the situation? {code} Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b811f539700 (LWP 3024)] HttpTransact::process_quick_http_filter (s=0x2b812c3dfb98, method=110) at HttpTransact.cc:6544 6544 if (!IpAllow::CheckMask(s->state_machine->ua_session->acl_method_mask, method)) { (gdb) bt #0 HttpTransact::process_quick_http_filter (s=0x2b812c3dfb98, method=110) at HttpTransact.cc:6544 #1 0x00554301 in HttpTransact::EndRemapRequest (s=0x2b812c3dfb98) at HttpTransact.cc:851 #2 0x0052f552 in HttpSM::call_transact_and_set_next_state (this=0x2b812c3dfb30, f=) at HttpSM.cc:6319 #3 0x0053e26a in HttpSM::set_next_state (this=0x2b812c3dfb30) at HttpSM.cc:6377 #4 0x0053e14c in HttpSM::set_next_state (this=0x2b812c3dfb30) at HttpSM.cc:6516 #5 0x0053e14c in HttpSM::set_next_state (this=0x2b812c3dfb30) at HttpSM.cc:6516 #6 0x00539961 in do_api_callout (this=0x2b812c3dfb30) at HttpSM.cc:499 #7 do_api_callout (this=0x2b812c3dfb30) at HttpSM.cc:504 #8 HttpSM::state_add_to_list (this=0x2b812c3dfb30, event=, data=) at HttpSM.cc:527 #9 0x0053a738 in HttpSM::main_handler (this=0x2b812c3dfb30, event=0, data=0x0) at HttpSM.cc:2440 #10 0x0056c267 in handleEvent (data=0x0, event=0, this=0x2b812c3dfb30) at ../../iocore/eventsystem/I_Continuation.h:146 #11 HttpUpdateSM::start_scheduled_update (this=0x2b812c3dfb30, cont=0x2b81201242c0, request=0x1246ab0) at HttpUpdateSM.cc:92 #12 0x004fbbf7 in UpdateSM::http_scheme (sm=0x2b81201242c0) at Update.cc:1567 #13 0x004f7008 in UpdateSM::HandleSMEvent (this=0x2b81201242c0, event=1, e=) at Update.cc:1478 #14 0x006a6380 in handleEvent (data=0x1202570, event=1, this=) at I_Continuation.h:146 #15 EThread::process_event (this=0x2b811f237010, e=0x1202570, calling_code=1) at UnixEThread.cc:142 #16 0x006a6f3b in EThread::execute (this=0x2b811f237010) at UnixEThread.cc:191 #17 0x006a5172 in spawn_thread_internal (a=0x11e27e0) at Thread.cc:88 #18 0x2b811b67ae2c in start_thread () from /lib64/libpthread.so.0 #19 0x2b811df5b3cd in clone () from /lib64/libc.so.6 (gdb) p s->state_machine->ua_session $1 = (HttpClientSession *) 0x0 (gdb) {code} > Crash Report: enable update will triger Segmentation fault > -- > > Key: TS-801 > URL: https://issues.apache.org/jira/browse/TS-801 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.8 > Environment: v2.1.8 and update function enabled. >Reporter: Zhao Yongming > Labels: update > Fix For: 3.1.4 > > > {code} > b13621367...@hotmail.com: NOTE: Traffic Server received Sig 11: Segmentation > fault > /usr/local/ts/bin/traffic_server - STACK TRACE: > b13621367...@hotmail.com: > /usr/local/ts/bin/traffic_server[0x5260c9] > /lib64/libpthread.so.0[0x3088e0f4c0] > [0x6e] > /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void > (*)(HttpTransact::State*))+0x6e)[0x57e0e2] > /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x18b)[0x57e369] > /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b] > /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void > (*)(HttpTransact::State*))+0x15e)[0x57e1d2] > /usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x56d9aa] > /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1] > /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3] > /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242] > /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b] > /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void > (*)(HttpTransact::State*))+0x15e)[0x57e1d2] > /usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x13b13621367...@hotmail.com: > 8)[0x56d9aa] > /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1] > /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3] > /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242] > /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b] > /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void > (*)(HttpTransact::State*))+0x15e)[0x57e1d2] > /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x36)[0x5b5cb0] > /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582
[jira] [Resolved] (TS-1176) Eliminate the delayed delete of LogBuffer
[ https://issues.apache.org/jira/browse/TS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1176. --- Resolution: Fixed > Eliminate the delayed delete of LogBuffer > - > > Key: TS-1176 > URL: https://issues.apache.org/jira/browse/TS-1176 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.4 > > > There's a race condition in another place in the code, and it's obvious to me > that this deferred delete was done to avoid this race condition. -- 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-1080) Assert under heavy load with logging enabled
[ https://issues.apache.org/jira/browse/TS-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1080. --- Resolution: Fixed Fixed in commit 3691e5dca658cc59885f803cc70c5616591d8b23 > Assert under heavy load with logging enabled > > > Key: TS-1080 > URL: https://issues.apache.org/jira/browse/TS-1080 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.1.4 > > > Given enough load (in the 100,000 QPS or more), we run out of some sort of > buffer space, with an assert of > {code} > #0 0x2ba719d50285 in __GI_raise (sig=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x2ba719d51b9b in __GI_abort () at abort.c:91 > #2 0x006b561a in ink_die_die_die (retval=) at > ink_error.cc:43 > #3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *) > (return_code=, message_format=, > ap=0x7fff7275a7d8) at ink_error.cc:65 > #4 0x006b56a7 in ink_fatal (return_code=, > message_format=) at ink_error.cc:73 > #5 0x006b4970 in _ink_assert (a=0x6fd380 > "_num_flush_buffers[_open_flush_array] < FLUSH_ARRAY_SIZE", f= out>, l=96) at ink_assert.cc:44 > #6 0x005a8b34 in add_to_flush_queue (buffer=0x2ba7443ca970, > this=0x22fb918) at LogObject.h:96 > #7 LogObject::_checkout_write (this=0x22fb880, write_offset=0x7fff7275add8, > bytes_needed=152) at LogObject.cc:455 > #8 0x005a8fd3 in LogObject::log (this=0x22fb880, lad=0x7fff7275b030, > text_entry=0x0) at LogObject.cc:580 > #9 0x0058e956 in log (lad=0x7fff7275b030, this=) at > LogObject.h:475 > #10 Log::access (lad=0x7fff7275b030) at Log.cc:1086 > {code} > Increasing FLUSH_ARRAY_SIZE alleviates the problem, but really, we shouldn't > end up in this situation at all. -- 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-801) Crash Report: enable update will triger Segmentation fault
[ https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243020#comment-13243020 ] Zhao Yongming commented on TS-801: -- {code} Program terminated with signal 11, Segmentation fault. #0 HttpTransact::process_quick_http_filter (s=0x2b65bc2a5b98, method=110) at HttpTransact.cc:6544 6544 if (!IpAllow::CheckMask(s->state_machine->ua_session->acl_method_mask, method)) { (gdb) bt #0 HttpTransact::process_quick_http_filter (s=0x2b65bc2a5b98, method=110) at HttpTransact.cc:6544 #1 0x00554301 in HttpTransact::EndRemapRequest (s=0x2b65bc2a5b98) at HttpTransact.cc:851 #2 0x0052f552 in HttpSM::call_transact_and_set_next_state (this=0x2b65bc2a5b30, f=) at HttpSM.cc:6319 #3 0x0053e26a in HttpSM::set_next_state (this=0x2b65bc2a5b30) at HttpSM.cc:6377 #4 0x0053e14c in HttpSM::set_next_state (this=0x2b65bc2a5b30) at HttpSM.cc:6516 #5 0x0053e14c in HttpSM::set_next_state (this=0x2b65bc2a5b30) at HttpSM.cc:6516 #6 0x00539961 in do_api_callout (this=0x2b65bc2a5b30) at HttpSM.cc:499 #7 do_api_callout (this=0x2b65bc2a5b30) at HttpSM.cc:504 #8 HttpSM::state_add_to_list (this=0x2b65bc2a5b30, event=, data=) at HttpSM.cc:527 #9 0x0053a738 in HttpSM::main_handler (this=0x2b65bc2a5b30, event=0, data=0x0) at HttpSM.cc:2440 #10 0x0056c267 in handleEvent (data=0x0, event=0, this=0x2b65bc2a5b30) at ../../iocore/eventsystem/I_Continuation.h:146 #11 HttpUpdateSM::start_scheduled_update (this=0x2b65bc2a5b30, cont=0x13e6880, request=0x2b65b0120e20) at HttpUpdateSM.cc:92 #12 0x004fbbf7 in UpdateSM::http_scheme (sm=0x13e6880) at Update.cc:1567 #13 0x004f7008 in UpdateSM::HandleSMEvent (this=0x13e6880, event=1, e=) at Update.cc:1478 #14 0x006a6380 in handleEvent (data=0x13ae130, event=1, this=) at I_Continuation.h:146 #15 EThread::process_event (this=0x2b65ad7c8010, e=0x13ae130, calling_code=1) at UnixEThread.cc:142 #16 0x006a6f3b in EThread::execute (this=0x2b65ad7c8010) at UnixEThread.cc:191 #17 0x0048b946 in main (argc=, argv=) at Main.cc:1841 (gdb) i threads Id Target Id Frame 21 Thread 0x2b65b6de5700 (LWP 3286) 0x2b65ac6eea53 in epoll_wait () from /lib64/libc.so.6 20 Thread 0x2b65adccc700 (LWP 3265) 0x2b65ac6eea53 in epoll_wait () from /lib64/libc.so.6 19 Thread 0x2b65b61d9700 (LWP 3272) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 18 Thread 0x2b65b7710700 (LWP 3346) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 17 Thread 0x2b65b760f700 (LWP 3345) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 16 Thread 0x2b65b7912700 (LWP 3347) 0x2b65a9e14f3d in accept () from /lib64/libpthread.so.0 15 Thread 0x2b65b730c700 (LWP 3344) 0x2b65a9e14f3d in accept () from /lib64/libpthread.so.0 14 Thread 0x2b65b7088700 (LWP 3341) 0x2b65a9e11d7c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 13 Thread 0x2b65b6be3700 (LWP 3280) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 12 Thread 0x2b65b69e1700 (LWP 3278) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 11 Thread 0x2b65b67df700 (LWP 3277) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x2b65b65dd700 (LWP 3276) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9Thread 0x2b65b63db700 (LWP 3275) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8Thread 0x2b65b5fd7700 (LWP 3270) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7Thread 0x2b65b5dd5700 (LWP 3269) 0x2b65a9e120fb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6Thread 0x2b65ae2d2700 (LWP 3268) 0x2b65ac6bdbfd in nanosleep () from /lib64/libc.so.6 5Thread 0x2b65ae0d0700 (LWP 3267) 0x2b65ac6bdbfd in nanosleep () from /lib64/libc.so.6 4Thread 0x2b65adece700 (LWP 3266) 0x2b65ac6bdbfd in nanosleep () from /lib64/libc.so.6 3Thread 0x2b65adbcb700 (LWP 3264) 0x2b65ac6eea53 in epoll_wait () from /lib64/libc.so.6 2Thread 0x2b65ad066700 (LWP 3261) 0x2b65ac6bdbfd in nanosleep () from /lib64/libc.so.6 * 1Thread 0x2b65acdfb340 (LWP 3260) HttpTransact::process_quick_http_filter (s=0x2b65bc2a5b98, method=110) at HttpTransact.cc:6544 (gdb) bt #0 HttpTransact::process_quick_http_filter (s=0x2b65bc2a5b98, method=110) at HttpTransact.cc:6544 #1 0x00554301 in HttpTransact::EndRemapRequest (s=0x2b65bc2a5b98) at HttpTransact.cc:851 #2 0x0052f552 in HttpSM::call_transact_and_set_next_state (this=0x2b65bc2a5b30, f=
[jira] [Created] (TS-1177) Download mirrors and cache hits
Download mirrors and cache hits --- Key: TS-1177 URL: https://issues.apache.org/jira/browse/TS-1177 Project: Traffic Server Issue Type: Improvement Reporter: Jack Bates I just applied to GSoC with a proposal to use RFC 6249 (Metalink/HTTP: Mirrors and Hashes) to discover requests for the same files from different mirrors and redirect clients to mirrors that are already cached I am filing this JIRA ticket describing my proposal to cause the Apache organization to process it [2]. Thanks for considering this proposal [1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/nottheoilrig/4001 [2] http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201203.mbox/%3CF28ED27B-8224-4362-B98C-945530CADC7C%40me.com%3E -- 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