[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507359#comment-13507359 ] Jan-Frode Myklebust commented on TS-1125: - It seems to be waiting more than a little while. We see a full 2 second delay for POST with large responses from origin server, on ATS 3.2.3. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.1 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-1146: --- Assignee: Phil Sorber (was: James Peach) RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: Phil Sorber Fix For: 3.3.1 Attachments: SSL_CTX_set_tlsext_ticket_key_cb.txt For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1086) Returning 304 response to unconditional request
[ https://issues.apache.org/jira/browse/TS-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507508#comment-13507508 ] Rob Lyon commented on TS-1086: -- I am seeing the same issue. I am seeing it on about 5% of the requests. The bad response (TCP_REFRESH_HIT/304) appears to be paired with a correct response (TCP_REFRESH_HIT/200) in the same second. The Via header is confirming a unconditional request (simple): ApacheTrafficServer/3.2.0 [uScSsNf pNeN:t cCSi p sS]. Returning 304 response to unconditional request --- Key: TS-1086 URL: https://issues.apache.org/jira/browse/TS-1086 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.1 Environment: Observed on Amazon/ec2 build, which is 3.0.1 on redhat-like linux. Reporter: Nick Kew Fix For: 3.3.1 ab is reporting HTTP 304 responses to a small number of unconditional requests in a test run: GET /testfile.html HTTP/1.0^M Host: localhost^M User-Agent: ApacheBench/2.3^M Accept: */*^M ^M HTTP/1.0 304 Not Modified^M Date: Mon, 21 Nov 2011 14:23:48 GMT^M Server: ATS/3.0.1^M ETag: 5e24-24cd-4b23b69f6e89c^M Cache-Control: max-age=60^M Age: 2^M ^M I presume what's happening is that trafficserver is sending a conditional request with If-Modified-Since to the origin server, and then returning the origin's 304 response to the client's unconditional request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1598) Coring in SSL
[
https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507515#comment-13507515
]
Bryan Call commented on TS-1598:
so the line that starts this mess is SSLNetVConnection.cc:135:
while (block_write_avail 0) {
int rres = SSL_read(sslvc-ssl, b-end() + offset,
(int)block_write_avail); --- this line
(gdb) info locals
rres = value optimized out
offset = value optimized out
s = 0x2b1f3c633350
sslvc = 0x2b1f3c633250
buf = @0x2b1f3c633378
bytes_read = 0
block_write_avail = 47430144907985 --- if that is the number of blocks that
seem crazy high
__func__ = ssl_read_from_net
b = 0x2b1f6b16f9b0
event = value optimized out
sslErr = 0
(gdb) p *b
$19 = {RefCountObj = {ForceVFPTToTop = {_vptr.ForceVFPTToTop = 0x6a41b0},
m_refcount = 1}, _start = 0x0, _end = 0x0,
_buf_end = 0x2b2330f05ad1 \272j,
_location = 0x6bcaa8 memory/IOBuffer/HttpClientSession.cc:235, data = {
m_ptr = 0x2b2088e31e00}, next = {m_ptr = 0x0}}
(gdb) p *sslvc-ssl
$20 = {version = 769, type = 8192, method = 0x3f96455840,
rbio = 0x2b1fbceed1c0, wbio = 0x2b1fbceed1c0, bbio = 0x0, rwstate = 1,
in_handshake = 0, handshake_func = 0x3f9621cd30 ssl3_accept, server = 1,
new_session = 0, quiet_shutdown = 1, shutdown = 0, state = 3, rstate = 240,
init_buf = 0x0, init_msg = 0x2b235cf40a34, init_num = 0, init_off = 0,
packet = 0x2b1f78d17d23 \027\003\001\b\t?xml version=\1.0\
encoding=\UTF-8\?\nA:propfind xmlns:A=\DAV:\\n A:prop\n
A:add-member/\nC:allowed-sharing-modes
xmlns:C=\http://calendarserver.org/ns/\/\nF:bulk-requests xmlns...,
packet_length = 0, s2 = 0x0, s3 = 0x2b1fbd066760, d1 = 0x0,
read_ahead = 0, msg_callback = 0, msg_callback_arg = 0x0, hit = 0,
param = 0x2b1fbd066720, cipher_list = 0x0, cipher_list_by_id = 0x0,
mac_flags = 0, enc_read_ctx = 0x2b1f81c70020, read_hash = 0x2b1f81c700d0,
expand = 0x0, enc_write_ctx = 0x2b1fbed76d90, write_hash = 0x2b1fbed76e40,
compress = 0x0, cert = 0x2b1fbd066640, sid_ctx_length = 0,
sid_ctx = '\000' repeats 31 times, session = 0x2b1fbd066e80,
generate_session_id = 0, verify_mode = 0, verify_callback = 0,
info_callback = 0, error = 0, error_code = 0, kssl_ctx = 0x2b1fbceed240,
psk_client_callback = 0, psk_server_callback = 0, ctx = 0x1916080,
debug = 0, verify_result = 0, ex_data = {sk = 0x2b1fbceed670, dummy = 0},
client_CA = 0x0, references = 1, options = 4194308, mode = 0,
max_cert_list = 102400, first_packet = 0, client_version = 769,
max_send_fragment = 16384, tlsext_debug_cb = 0, tlsext_debug_arg = 0x0,
tlsext_hostname = 0x0, servername_done = 0, tlsext_status_type = -1,
tlsext_status_expected = 0, tlsext_ocsp_ids = 0x0, tlsext_ocsp_exts = 0x0,
tlsext_ocsp_resp = 0x0, tlsext_ocsp_resplen = -1,
tlsext_ticket_expected = 0, tlsext_opaque_prf_input = 0x0,
tlsext_opaque_prf_input_len = 0, tlsext_session_ticket = 0x0,
tls_session_ticket_ext_cb = 0, tls_session_ticket_ext_cb_arg = 0x0,
tls_session_secret_cb = 0, tls_session_secret_cb_arg = 0x0,
initial_ctx = 0x1916080}
Coring in SSL
-
Key: TS-1598
URL: https://issues.apache.org/jira/browse/TS-1598
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6.2 64bit
Reporter: Abhishek Nayani
(gdb) bt
#0 0x00390ac88c5b in memcpy () from /lib64/libc.so.6
#1 0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10
#2 0x003f9670 in ?? () from /usr/lib64/libssl.so.10
#3 0x0066eaf7 in ssl_read_from_net (nh=value optimized out,
vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at
SSLNetVConnection.cc:135
#4 0x0066f3b0 in SSLNetVConnection::net_read_io
(this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at
SSLNetVConnection.cc:288
#5 0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8,
event=value optimized out, e=value optimized out) at UnixNet.cc:381
#6 0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0,
calling_code=5) at I_Continuation.h:146
#7 EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5)
at UnixEThread.cc:142
#8 0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at
UnixEThread.cc:264
#9 0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88
#10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0
#11 0x00390ace76dd in clone () from /lib64/libc.so.6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1598) Coring in SSL
[
https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507515#comment-13507515
]
Bryan Call edited comment on TS-1598 at 11/30/12 6:34 PM:
--
so the line that starts this mess is SSLNetVConnection.cc:135:
while (block_write_avail 0) {
int rres = SSL_read(sslvc-ssl, b-end() + offset,
(int)block_write_avail); --- this line
(gdb) info locals
rres = value optimized out
offset = value optimized out
s = 0x2b1f3c633350
sslvc = 0x2b1f3c633250
buf = @0x2b1f3c633378
bytes_read = 0
block_write_avail = 47430144907985 --- if that is the number of bytes that
seem crazy high
__func__ = ssl_read_from_net
b = 0x2b1f6b16f9b0
event = value optimized out
sslErr = 0
(gdb) p *b
$19 = {RefCountObj = {ForceVFPTToTop = {_vptr.ForceVFPTToTop = 0x6a41b0},
m_refcount = 1}, _start = 0x0, _end = 0x0,
_buf_end = 0x2b2330f05ad1 \272j,
_location = 0x6bcaa8 memory/IOBuffer/HttpClientSession.cc:235, data = {
m_ptr = 0x2b2088e31e00}, next = {m_ptr = 0x0}}
(gdb) p *sslvc-ssl
$20 = {version = 769, type = 8192, method = 0x3f96455840,
rbio = 0x2b1fbceed1c0, wbio = 0x2b1fbceed1c0, bbio = 0x0, rwstate = 1,
in_handshake = 0, handshake_func = 0x3f9621cd30 ssl3_accept, server = 1,
new_session = 0, quiet_shutdown = 1, shutdown = 0, state = 3, rstate = 240,
init_buf = 0x0, init_msg = 0x2b235cf40a34, init_num = 0, init_off = 0,
packet = 0x2b1f78d17d23 \027\003\001\b\t?xml version=\1.0\
encoding=\UTF-8\?\nA:propfind xmlns:A=\DAV:\\n A:prop\n
A:add-member/\nC:allowed-sharing-modes
xmlns:C=\http://calendarserver.org/ns/\/\nF:bulk-requests xmlns...,
packet_length = 0, s2 = 0x0, s3 = 0x2b1fbd066760, d1 = 0x0,
read_ahead = 0, msg_callback = 0, msg_callback_arg = 0x0, hit = 0,
param = 0x2b1fbd066720, cipher_list = 0x0, cipher_list_by_id = 0x0,
mac_flags = 0, enc_read_ctx = 0x2b1f81c70020, read_hash = 0x2b1f81c700d0,
expand = 0x0, enc_write_ctx = 0x2b1fbed76d90, write_hash = 0x2b1fbed76e40,
compress = 0x0, cert = 0x2b1fbd066640, sid_ctx_length = 0,
sid_ctx = '\000' repeats 31 times, session = 0x2b1fbd066e80,
generate_session_id = 0, verify_mode = 0, verify_callback = 0,
info_callback = 0, error = 0, error_code = 0, kssl_ctx = 0x2b1fbceed240,
psk_client_callback = 0, psk_server_callback = 0, ctx = 0x1916080,
debug = 0, verify_result = 0, ex_data = {sk = 0x2b1fbceed670, dummy = 0},
client_CA = 0x0, references = 1, options = 4194308, mode = 0,
max_cert_list = 102400, first_packet = 0, client_version = 769,
max_send_fragment = 16384, tlsext_debug_cb = 0, tlsext_debug_arg = 0x0,
tlsext_hostname = 0x0, servername_done = 0, tlsext_status_type = -1,
tlsext_status_expected = 0, tlsext_ocsp_ids = 0x0, tlsext_ocsp_exts = 0x0,
tlsext_ocsp_resp = 0x0, tlsext_ocsp_resplen = -1,
tlsext_ticket_expected = 0, tlsext_opaque_prf_input = 0x0,
tlsext_opaque_prf_input_len = 0, tlsext_session_ticket = 0x0,
tls_session_ticket_ext_cb = 0, tls_session_ticket_ext_cb_arg = 0x0,
tls_session_secret_cb = 0, tls_session_secret_cb_arg = 0x0,
initial_ctx = 0x1916080}
was (Author: bcall):
so the line that starts this mess is SSLNetVConnection.cc:135:
while (block_write_avail 0) {
int rres = SSL_read(sslvc-ssl, b-end() + offset,
(int)block_write_avail); --- this line
(gdb) info locals
rres = value optimized out
offset = value optimized out
s = 0x2b1f3c633350
sslvc = 0x2b1f3c633250
buf = @0x2b1f3c633378
bytes_read = 0
block_write_avail = 47430144907985 --- if that is the number of blocks that
seem crazy high
__func__ = ssl_read_from_net
b = 0x2b1f6b16f9b0
event = value optimized out
sslErr = 0
(gdb) p *b
$19 = {RefCountObj = {ForceVFPTToTop = {_vptr.ForceVFPTToTop = 0x6a41b0},
m_refcount = 1}, _start = 0x0, _end = 0x0,
_buf_end = 0x2b2330f05ad1 \272j,
_location = 0x6bcaa8 memory/IOBuffer/HttpClientSession.cc:235, data = {
m_ptr = 0x2b2088e31e00}, next = {m_ptr = 0x0}}
(gdb) p *sslvc-ssl
$20 = {version = 769, type = 8192, method = 0x3f96455840,
rbio = 0x2b1fbceed1c0, wbio = 0x2b1fbceed1c0, bbio = 0x0, rwstate = 1,
in_handshake = 0, handshake_func = 0x3f9621cd30 ssl3_accept, server = 1,
new_session = 0, quiet_shutdown = 1, shutdown = 0, state = 3, rstate = 240,
init_buf = 0x0, init_msg = 0x2b235cf40a34, init_num = 0, init_off = 0,
packet = 0x2b1f78d17d23 \027\003\001\b\t?xml version=\1.0\
encoding=\UTF-8\?\nA:propfind xmlns:A=\DAV:\\n A:prop\n
A:add-member/\nC:allowed-sharing-modes
xmlns:C=\http://calendarserver.org/ns/\/\nF:bulk-requests xmlns...,
packet_length = 0, s2 = 0x0, s3 = 0x2b1fbd066760, d1 = 0x0,
read_ahead = 0, msg_callback = 0, msg_callback_arg = 0x0, hit = 0,
param = 0x2b1fbd066720, cipher_list = 0x0, cipher_list_by_id = 0x0,
mac_flags = 0, enc_read_ctx = 0x2b1f81c70020, read_hash = 0x2b1f81c700d0,
expand =
[jira] [Created] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
Yakov Markovitch created TS-1606:
Summary: Log buffers are not flushed periodically when TS is
launched with NO_REMOTE_MANAGEMENT flag
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Yakov Markovitch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when launched
not as a daemon but directly - this is extremely convenient for debugging), the
PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-1606:
-
Affects Version/s: 3.3.0
3.2.0
Log buffers are not flushed periodically when TS is launched with
NO_REMOTE_MANAGEMENT flag
---
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
launched not as a daemon but directly - this is extremely convenient for
debugging), the PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-1606:
-
Attachment: trafficserver-periodic-tasks.patch
This patch both fixes the bug and removes some dead code in logging
initialization.
Log buffers are not flushed periodically when TS is launched with
NO_REMOTE_MANAGEMENT flag
---
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
Attachments: trafficserver-periodic-tasks.patch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
launched not as a daemon but directly - this is extremely convenient for
debugging), the PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1598) Coring in SSL
[
https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507563#comment-13507563
]
Bryan Call commented on TS-1598:
A few things to note:
1. The _start and _end are not set in the IOBufferBlock - default values of 0x0
2. When write_avail is called on the buffer block it takes the _buf_end pointer
and subtracts _end giving the crazy high number of bytes available to write
3. b-end() + offset in the code will be a very low memory address since _end
== 0x0
Looking at the MIOBuffer:
(gdb) p *buf.mbuf
$6 = {size_index = 47430144908000, water_mark = 0, _writer = {
m_ptr = 0x2b1f6b16f9b0}, readers = {{accessor = 0x0, mbuf = 0x0, block = {
m_ptr = 0x0}, start_offset = 0, size_limit = 9223372036854775807}, {
accessor = 0x0, mbuf = 0x0, block = {m_ptr = 0x0}, start_offset = 0,
size_limit = 9223372036854775807}, {accessor = 0x0, mbuf = 0x0, block = {
m_ptr = 0x0}, start_offset = 0, size_limit = 9223372036854775807}, {
accessor = 0x0, mbuf = 0x0, block = {m_ptr = 0x0}, start_offset = 0,
size_limit = 9223372036854775807}, {accessor = 0x0, mbuf = 0x0, block = {
m_ptr = 0x0}, start_offset = 0, size_limit = 9223372036854775807}},
_location = 0x6bcaa8 memory/IOBuffer/HttpClientSession.cc:235}
Coring in SSL
-
Key: TS-1598
URL: https://issues.apache.org/jira/browse/TS-1598
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6.2 64bit
Reporter: Abhishek Nayani
(gdb) bt
#0 0x00390ac88c5b in memcpy () from /lib64/libc.so.6
#1 0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10
#2 0x003f9670 in ?? () from /usr/lib64/libssl.so.10
#3 0x0066eaf7 in ssl_read_from_net (nh=value optimized out,
vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at
SSLNetVConnection.cc:135
#4 0x0066f3b0 in SSLNetVConnection::net_read_io
(this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at
SSLNetVConnection.cc:288
#5 0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8,
event=value optimized out, e=value optimized out) at UnixNet.cc:381
#6 0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0,
calling_code=5) at I_Continuation.h:146
#7 EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5)
at UnixEThread.cc:142
#8 0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at
UnixEThread.cc:264
#9 0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88
#10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0
#11 0x00390ace76dd in clone () from /lib64/libc.so.6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1606:
-
Assignee: Leif Hedstrom
Log buffers are not flushed periodically when TS is launched with
NO_REMOTE_MANAGEMENT flag
---
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
Assignee: Leif Hedstrom
Attachments: trafficserver-periodic-tasks.patch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
launched not as a daemon but directly - this is extremely convenient for
debugging), the PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1606:
--
Fix Version/s: 3.3.1
Log buffers are not flushed periodically when TS is launched with
NO_REMOTE_MANAGEMENT flag
---
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
Assignee: Leif Hedstrom
Fix For: 3.3.1
Attachments: trafficserver-periodic-tasks.patch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
launched not as a daemon but directly - this is extremely convenient for
debugging), the PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
