[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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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=optimized out) 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=optimized out,
data=optimized out) 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=optimized out) at Update.cc:1478
#14 0x006a6380 in handleEvent (data=0x1202570, event=1, this=optimized
out) 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]
[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=optimized out) at
ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=optimized out, message_format=optimized out,
ap=0x7fff7275a7d8) at ink_error.cc:65
#4 0x006b56a7 in ink_fatal (return_code=optimized out,
message_format=optimized out) at ink_error.cc:73
#5 0x006b4970 in _ink_assert (a=0x6fd380
_num_flush_buffers[_open_flush_array] FLUSH_ARRAY_SIZE, f=optimized
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=optimized out) 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-tabpanelfocusedCommentId=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=optimized out) 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=optimized out,
data=optimized out) 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=optimized out) at Update.cc:1478
#14 0x006a6380 in handleEvent (data=0x13ae130, event=1, this=optimized
out) 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=optimized out, argv=optimized out) 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
