[jira] [Created] (TS-1102) Cleanup obsolete debugging code

[Uri Shachar (Created) (JIRA)]

Cleanup obsolete debugging code
---

 Key: TS-1102
 URL: https://issues.apache.org/jira/browse/TS-1102
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Logging, Performance
Affects Versions: 3.0.2
 Environment: Any
Reporter: Uri Shachar
Priority: Minor


The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 
for all compilation environments, and it includes variadic argument macro 
support with ##_VA_ARGS_ that deletes the final comma if no arguments are 
provided.
Removing the added layer should also improve performance when high volume 
debugging is turned on.

--
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-1079) Add an API function to turn debugging on for specific transactions/sessions

[Uri Shachar (Created) (JIRA)]

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
Priority: Minor


  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-1032) Assertion when upstream connection is established (with event handled by thread A) and immediately disconnected (handled by thread B)

[Uri Shachar (Created) (JIRA)]

Assertion when upstream connection is established (with event handled by thread 
A) and immediately disconnected (handled by thread B)
-

 Key: TS-1032
 URL: https://issues.apache.org/jira/browse/TS-1032
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, HTTP
Affects Versions: 3.1.1
 Environment: Linux 32bit CentOS 5.4. Pre-open source version of ATS.
Reporter: Uri Shachar


This happened twice on a very old version of ATS (pre opensource code), but it 
looks like it can happen in current ATS as well (it's a very rare race 
condition, haven't been able to reproduce).

Scenario:
1)  Client request arrives, handled by TS thread 1 and is reenabled 
by a plugin (Inside a continuation called by ContSched)
2)  TS thread 2 starts to connect upstream
3)  A client disconnection event is placed in thread 1 queue.
4)  A successful connection event is placed in thread 2 queue.
5)  Thread 1 starts to handle pending events (setting cur_time to X)
6)  Thread 2 starts to handle pending events (setting cur_time to 
Z=X+Y)
7)  Thread 2 handles the connection established event (setting 
server_first_connect to Z)
8)  Thread 1 handles the client disconnection event - Getting a 
negative wait and asserting...

Sample stack trace:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xe3131b90 (LWP 14584)]
0xe410 in __kernel_vsyscall ()
#0  0xe410 in __kernel_vsyscall ()
#1  0x007e2df0 in raise () from /lib/libc.so.6
#2  0x007e484e in abort () from /lib/libc.so.6
#3  0x08427612 in ink_die_die_die (retval=1) at 
/usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:45
#4  0x08427778 in ink_fatal_va (return_code=1, message_format=0xe312ee1f 
/tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572: 
failed assert `wait = 0`, ap=0xe312ee08 \002) at 
/usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:100
#5  0x084277d3 in ink_fatal (return_code=1, message_format=0xe312ee1f 
/tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572: 
failed assert `wait = 0`) at 
/usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:111
#6  0x08424508 in _ink_assert (a=0x853db72 wait = 0, f=0x853ab3c 
/tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc, 
l=5572) at /usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_assert.cc:27
#7  0x082f2505 in HttpSM::mark_server_down_on_client_abort (this=0xb622ece0) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572
#8  0x082f6080 in HttpSM::state_watch_for_client_abort (this=0xb622ece0, 
event=3, data=0x7e0e2a88) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:1148
#9  0x082fad0f in HttpSM::main_handler (this=0xb622ece0, event=3, 
data=0x7e0e2a88) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:3213
#10 0x0810a07b in Continuation::handleEvent (this=0xb622ece0, event=3, 
data=0x7e0e2a88) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/Continuation.h:85
#11 0x083ab348 in read_signal_and_update (event=3, vc=0x7e0e2a30) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:262
#12 0x083ab3fe in read_signal_done (event=3, nh=0xa339b28, vc=0x7e0e2a30) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:300
#13 0x083ab44f in read_signal_error (nh=0xa339b28, vc=0x7e0e2a30, lerrno=104) 
at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:324
#14 0x083ae1c5 in read_from_net (nh=0xa339b28, vc=0x7e0e2a30, thread=0xa32e490) 
at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:783
#15 0x083ae5a7 in UnixNetVConnection::net_read_io (this=0x7e0e2a30, 
nh=0xa339b28, lthread=0xa32e490) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:1059
#16 0x083adced in NetHandler::mainNetEvent (this=0xa339b28, event=5, 
e=0xa1ab810) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:1272
#17 0x0810a07b in Continuation::handleEvent (this=0xa339b28, event=5, 
data=0xa1ab810) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/Continuation.h:85
#18 0x083a19ac in EThread::process_event (this=0xa32e490, e=0xa1ab810, 
calling_code=5) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixEThread.cc:132
#19 0x0839f800 in EThread::execute (this=0xa32e490) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixEThread.cc:315
#20 0x083b4f9a in spawn_thread_internal (a=0xa385360) at 
/usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixThread.cc:71
#21 0x009065ab in start_thread () from /lib/libpthread.so.0
#22 0x0088bcfe in clone () from /lib/libc.so.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: