[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
