[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001605#comment-14001605 ] Shaun McGinnity commented on TS-2497: - Hi Brian, is this the final patch? Also, does this replace the original patch that removed the call to deallocate_buffers? Thanks, Shaun Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 Attachments: TS-2497.patch, repro.js When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal (this=0x2aab38001130, b=0x2aab0c037200) at ../iocore/eventsystem/P_IOBuffer.h:946 #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:994 #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1002 #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1048 #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 #7 0x006c37bf in UnixNetVConnection::net_read_io (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at UnixNetVConnection.cc:816 #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, event=5, e=0x271d8e0) at UnixNet.cc:380 #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at UnixEThread.cc:264 #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001613#comment-14001613 ] Shaun McGinnity commented on TS-2497: - One more comment, we have also applied the patch for https://issues.apache.org/jira/browse/TS-1425 - do you think we still need this patch? Failed post results in tunnel buffers being returned to freelist prematurely Key: TS-2497 URL: https://issues.apache.org/jira/browse/TS-2497 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 Attachments: TS-2497.patch, repro.js When a post fails to an origin server either the server died or the server returned a response without reading all of the post data, in either case, TS will destroy buffers too early. This normally does not result in a crash because the MIOBuffers are returned to the freelist and only with sufficient load will the race happen causing a crash. Additionally, even if a crash doesn't happen you might have data corruption across post requests from the buffers being used after being returned to the freelist. Thanks to Thomas Jackson for help reproducing and resolving this bug. An example stack trace, while we've seen other crashes in write_avail too. #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at ../iocore/eventsystem/I_IOBuffer.h:362 #1 0x0050d151 in MIOBuffer::append_block_internal (this=0x2aab38001130, b=0x2aab0c037200) at ../iocore/eventsystem/P_IOBuffer.h:946 #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:994 #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1002 #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at ../iocore/eventsystem/P_IOBuffer.h:1048 #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 #7 0x006c37bf in UnixNetVConnection::net_read_io (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at UnixNetVConnection.cc:816 #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, event=5, e=0x271d8e0) at UnixNet.cc:380 #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at UnixEThread.cc:264 #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2817) ATS crash in SSLNetVConnection::load_buffer_and_write
[
https://issues.apache.org/jira/browse/TS-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2817:
--
Description:
Our production host running latest master crashed with the below stack traces.
Based on the stack traces, this might be related to a recent jira TS-2815. On
second thought, this may also be a duplicate of TS-2776.
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b8c4da4f500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6fbb6f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x368)[0x70f938]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b8c4da47851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[example_alarm_bin.sh] sent alarm: l10.ycs.sjb.yahoo.com [Sat May 17 20:13:29
2014] The TS-TM connection is broken for some reason. Either restart TS and TM
or correct this error for TM
to display TS statistics correctly
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2aed4fbcc500]
/lib64/libc.so.6(memcpy+0x15b)[0x3296e8997b]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x2f)[0x60f11f]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x6114e0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x61d1e2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPKc+0x319)[0x628ba9]
/home/y/bin/traffic_server(_ZN16LogObjectManager3logEP9LogAccess+0x5e)[0x6295be]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x5d8)[0x599ce8]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x7a0)[0x5a4a40]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x188)[0x5a4dc8]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xe0)[0x5e7050]
/home/y/bin/traffic_server[0x70d6f1]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x95b)[0x70ff2b]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2aed4fbc4851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log == [TrafficManager] using root directory '/
{code}
was:
Our production host running latest master crashed with the below stack traces.
Based on the stack traces, this might be related to a recent jira TS-2815.
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b8c4da4f500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6fbb6f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x368)[0x70f938]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b8c4da47851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[example_alarm_bin.sh] sent alarm: l10.ycs.sjb.yahoo.com [Sat May 17 20:13:29
2014] The TS-TM connection is broken for some reason. Either restart TS and TM
or correct this error for TM
to display TS statistics correctly
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2aed4fbcc500]
[jira] [Updated] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-153: -- Fix Version/s: (was: 5.0.0) 5.1.0 Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.1.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-698) LogFilter should support an actual IP type and matching rules
[
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-698:
--
Fix Version/s: (was: 5.0.0)
5.1.0
LogFilter should support an actual IP type and matching rules
-
Key: TS-698
URL: https://issues.apache.org/jira/browse/TS-698
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Affects Versions: 2.1.6
Environment: N/A
Reporter: Eric Connell
Assignee: Alan M. Carroll
Priority: Minor
Labels: review
Fix For: 5.1.0
Attachments: logfilterip.patch
The LogFilter configuration in logs_xml.config should support a native IPv4
and IPv6 filtering. For example, it would be handy to be able to filter out
log lines from a specific server or netblock. For example, the following
config would reject log lines for all hosts in the 10/8 network:
{code}
LogFilter
Name = local_net/
Condition = chi MATCH 10.0.0.0/8/
Action = REJECT/
/LogFilter
LogFormat
Name = access_log/
Format = %shi/
/LogFormat
LogObject
Format = access_log/
Filename = access_log/
Filters = local_net/
/LogObject
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-727) Do we need support for streams partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-727: -- Fix Version/s: (was: sometime) 5.1.0 Do we need support for streams partitions? Key: TS-727 URL: https://issues.apache.org/jira/browse/TS-727 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.1.0 There's code in the cache related to MIXT streams volumes (caches). Since we don't support streams, I'm thinking this code could be removed? Or alternatively, we should expose APIs so that someone writing a plugin and wish to store a different protocol (e.g. QT) can register this media type with the API and core. The idea being that the core only contains protocols that are in the core, but expose the cache core so that plugins can take advantage of it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-935: -- Fix Version/s: (was: 5.0.0) sometime Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT Key: TS-935 URL: https://issues.apache.org/jira/browse/TS-935 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Brian Geffon Labels: api-change Fix For: sometime When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon the fact that the API will decrement the event count for EVENT_INTERNAL or EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT because as of now doing so would cause m_event_count to become -1 or shouldn't these defined values be something different? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-852) hostdb and dns system hangup
[
https://issues.apache.org/jira/browse/TS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001879#comment-14001879
]
Bryan Call commented on TS-852:
---
[~psudaemon]
Can you decide what to do on this one? Close it for 5.0 or move it to the 5.1
release.
hostdb and dns system hangup
Key: TS-852
URL: https://issues.apache.org/jira/browse/TS-852
Project: Traffic Server
Issue Type: Bug
Components: Core, DNS
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Assignee: Phil Sorber
Priority: Minor
Labels: dns, hostdb
Fix For: 3.1.0, 5.0.0
Attachments: TS-852.patch
in my testing, all request that need go OS, fails with 30s timeout, and the
slow query shows data from dns missed:
{code}
[Jun 22 15:33:47.183] Server {1106880832} ERROR: [8122411] Slow Request: url:
http://download.im.alisoft.com/aliim/AliIM6/update/packages//2011-5-4-10-10-40/0/modulesproxy/8203.xml.wwzip
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.667 sm_finish: 30.667
[Jun 22 15:33:47.220] Server {1099663680} ERROR: [8122422] Slow Request: url:
http://img.uu1001.cn/materials/original/2010-11-22/22-48/a302876929a9c40a8272ac439a16ad25e74edf71.png
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.318 sm_finish: 30.318
[Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122421] Slow Request: url:
http://img02.taobaocdn.com/bao/uploaded/i2/T1mp8QXopdXXblNIZ6_061203.jpg_b.jpg
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.597 sm_finish: 30.597
[Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122409] Slow Request: url:
http://img04.taobaocdn.com/tps/i4/T1EM9gXltt-440-135.jpg status: 0
unique id: bytes: 0 fd: 0 client state: 6 server state: 0 ua_begin: 0.000
ua_read_header_done: 0.000 cache_open_read_begin: 0.000 cache_open_read_end:
0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000 server_connect: -1.000
server_first_read: -1.000 server_read_header_done: -1.000 server_close:
-1.000 ua_close: 30.948 sm_finish: 30.948
{code}
all http SM show from {http} in DNS_LOOKUP
and traffic.out show nothing with error, when I enable debug on
hostdb.*|dns.*:
{code}
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) probe
img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) timeout 64204
1308663404 300
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) delaying force 0
answer for img03.taobaocdn.com [timeout 0]
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) probe
img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) timeout 64204
1308663404 300
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) DNS
img03.taobaocdn.com
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) enqueuing
additional request
[Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) probe 127.0.0.1
E9B7563422C93608 1 [ignore_timeout = 0]
[Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) immediate
answer for 127.0.0.1
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) probe
img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) timeout 64281
1308663327 300
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) delaying force 0
answer for img08.taobaocdn.com [timeout 0]
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) probe
img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) timeout 64281
1308663327 300
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) DNS
img08.taobaocdn.com
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) enqueuing
additional request
[Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb) probe 127.0.0.1
E9B7563422C93608 1
[jira] [Updated] (TS-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1015: --- Fix Version/s: (was: 5.0.0) sometime TSEvent is widely declared as int - Key: TS-1015 URL: https://issues.apache.org/jira/browse/TS-1015 Project: Traffic Server Issue Type: Bug Components: Cleanup Reporter: Nick Kew Assignee: Igor Galić Priority: Minor Labels: api-change Fix For: sometime TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is declared as type int. This makes it harder to follow/debug using tools like *trace or gdb. This may usefully be fixed as and when people encounter instances of it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1015: --- Assignee: (was: Igor Galić) TSEvent is widely declared as int - Key: TS-1015 URL: https://issues.apache.org/jira/browse/TS-1015 Project: Traffic Server Issue Type: Bug Components: Cleanup Reporter: Nick Kew Priority: Minor Labels: api-change Fix For: sometime TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is declared as type int. This makes it harder to follow/debug using tools like *trace or gdb. This may usefully be fixed as and when people encounter instances of it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1033) Add some missing WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1033: --- Fix Version/s: (was: 5.0.0) 5.1.0 Add some missing WKS's to HdrToken. - Key: TS-1033 URL: https://issues.apache.org/jira/browse/TS-1033 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.1.0 And of course various other places (including InkAPI). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-727) Do we need support for streams partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-727: -- Fix Version/s: (was: 5.0.0) sometime Do we need support for streams partitions? Key: TS-727 URL: https://issues.apache.org/jira/browse/TS-727 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.1.0 There's code in the cache related to MIXT streams volumes (caches). Since we don't support streams, I'm thinking this code could be removed? Or alternatively, we should expose APIs so that someone writing a plugin and wish to store a different protocol (e.g. QT) can register this media type with the API and core. The idea being that the core only contains protocols that are in the core, but expose the cache core so that plugins can take advantage of it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-1141) Server intercept performance problems.
[ https://issues.apache.org/jira/browse/TS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-1141. -- Resolution: Fixed Fix Version/s: (was: 5.0.0) Can't duplicate issue Server intercept performance problems. -- Key: TS-1141 URL: https://issues.apache.org/jira/browse/TS-1141 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom It seems server intercept plugins are fairly expensive. A very simple one, serving a few bytes out of RAM, can only do in the order of 20K QPS, whereas the same server serving out of RAM cache do wo 175k QPS. I know there will be overhead in plugin APIs, but almost 10x seems quite high. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1509) Remove TS_PARSE_OK constant
[ https://issues.apache.org/jira/browse/TS-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1509: --- Fix Version/s: (was: 5.0.0) sometime Remove TS_PARSE_OK constant --- Key: TS-1509 URL: https://issues.apache.org/jira/browse/TS-1509 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Priority: Minor Labels: api-change Fix For: sometime There's TS_PARSE_DONE and TS_PARSE_OK. Which one should a developer handle and what's the difference between? Well TS_PARSE_OK is never returned from TSHttpParseResp() so we should just remove it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-1411) Seg fault when using %cquuc
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-1411:
--
Assignee: Bryan Call (was: Yunkai Zhang)
Seg fault when using %cquuc
-
Key: TS-1411
URL: https://issues.apache.org/jira/browse/TS-1411
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: RHEL 6.2 x86_64
Reporter: David Carlin
Assignee: Bryan Call
Priority: Critical
Labels: Crash
Fix For: 5.0.0
Attachments: Log rotation segaults.txt, TS-1411 backtraces.txt, cquuc
segfault patch.txt
I've been experiencing some segfaults during log rotation. The sequence of
events is this.. log rotation occurs, then I get hundreds of dropping log
buffer error msgs, then the segfault.
This started occurring when I lengthened the default log format to include
the unmapped URL and the user agent string:
%cqtq %ttms %chi %crc/%pssc %psql %cqhm %cquc %caun
%phr/%pqsn %psct %xid %cquuc \%{User-Agent}cqh\
In terms of frequency, we have a number of boxes and I probably see one of
these crashed per day since the above change. Logs are rotated every 2 hours.
I've had other log related segfaults, reported in TS-1330 - these new ones
seem to have a different cause.
[Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
was auto-deleted; 3148252 bytes were reclaimed.
[Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
was auto-deleted; 14735520048 bytes were reclaimed.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[...]
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x383f00f500]
/home/y/bin/traffic_server(LogAccess::marshal_mem(char*, char const*, int,
int)+0x48)[0x58a118]
/home/y/bin/traffic_server(LogAccessHttp::marshal_client_req_url_canon(char*)+0x20)[0x58c3f0]
/home/y/bin/traffic_server(LogFieldList::marshal(LogAccess*,
char*)+0x32)[0x59d5a2]
/home/y/bin/traffic_server(LogObject::log(LogAccess*, char*)+0x399)[0x5a7ed9]
/home/y/bin/traffic_server(Log::access(LogAccess*)+0x146)[0x58f506]
/home/y/bin/traffic_server(HttpSM::update_stats()+0x630)[0x526c50]
/home/y/bin/traffic_server(HttpSM::kill_this()+0x928)[0x52b548]
/home/y/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x52b868]
/home/y/bin/traffic_server(HttpTunnel::main_handler(int,
void*)+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x673871]
/home/y/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x847)[0x6756e7]
/home/y/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x286)[0x66e076]
/home/y/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x696ce4]
/home/y/bin/traffic_server(EThread::execute()+0x4c3)[0x697673]
/home/y/bin/traffic_server[0x695cb2]
/lib64/libpthread.so.0[0x383f007851]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1570) remap doesn't reject request whose Host has extra characters after port (like test.com:80xxx)
[ https://issues.apache.org/jira/browse/TS-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1570: -- Assignee: (was: Igor Galić) remap doesn't reject request whose Host has extra characters after port (like test.com:80xxx) --- Key: TS-1570 URL: https://issues.apache.org/jira/browse/TS-1570 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: Conan Wang Priority: Minor Fix For: sometime remap.config:map http://test.com http://1.1.1.1 The request with Host: 'test.com:80xxx' or 'test.com:xxx' will get passed. Such host is not filtered strictly. Just report, didn't have big problem for me though. curl http://127.0.0.1:8080/ -H Host: test.com:80xxx or curl -x 127.0.0.1:8080 http://test.com:80xxx/ -v -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1570) remap doesn't reject request whose Host has extra characters after port (like test.com:80xxx)
[ https://issues.apache.org/jira/browse/TS-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1570: -- Fix Version/s: (was: 5.0.0) sometime remap doesn't reject request whose Host has extra characters after port (like test.com:80xxx) --- Key: TS-1570 URL: https://issues.apache.org/jira/browse/TS-1570 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: Conan Wang Assignee: Igor Galić Priority: Minor Fix For: sometime remap.config:map http://test.com http://1.1.1.1 The request with Host: 'test.com:80xxx' or 'test.com:xxx' will get passed. Such host is not filtered strictly. Just report, didn't have big problem for me though. curl http://127.0.0.1:8080/ -H Host: test.com:80xxx or curl -x 127.0.0.1:8080 http://test.com:80xxx/ -v -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001891#comment-14001891
]
Bryan Call commented on TS-1547:
[~wbardwel]
Please submit your patch for 5.0 release or move out to 5.1.
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: William Bardwell
Labels: A, crash
Fix For: 5.0.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-1590) use_remap_processor crashes if share_server_sessions = 2
[
https://issues.apache.org/jira/browse/TS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-1590:
--
Assignee: Bryan Call
use_remap_processor crashes if share_server_sessions = 2
Key: TS-1590
URL: https://issues.apache.org/jira/browse/TS-1590
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.0
Reporter: Conan Wang
Assignee: Bryan Call
Priority: Critical
Labels: Crash
Fix For: 5.0.0
easy to reproduce:
{code}
CONFIG proxy.config.remap.use_remap_processor INT 1 (default is 0)
CONFIG proxy.config.http.share_server_sessions INT 2 (0, 1 will be ok)
{code}
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1210
[Switching to process 8927 thread 0x1a03]
0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
(gdb) bt
#0 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
#1 0x0001000eb366 in HttpSessionManager::acquire_session
(this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19
127.0.0.1, ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
#2 0x000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0,
raw=false) at HttpSM.cc:4384
..
(gdb) p this_ethread()-l1_hash
$2 = (SessionBucket *) 0x0
(gdb) p this_ethread()-event_types
$3 = 2 (ET_REMAP)
{code}
Using separate remap processor is a hidden option, and I enable it by
accident.. (Does anyone use it in prod?)
I noticed HttpSM::do_http_server_open is always executed by the remap
processer ethread (because of
action.continuation-handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if
wrong). While the remap thread was not initialized as ET_NET and has no
l1_hash, server session lookup in this ET_REMAP thread will crash.
I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on
ET_NET. So a fast workaround would be falling back to global server
connection when use_remap_processor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1633) add new stat sync type: TS_STAT_SYNC_MAX
[ https://issues.apache.org/jira/browse/TS-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1633: --- Fix Version/s: (was: 5.0.0) sometime add new stat sync type: TS_STAT_SYNC_MAX Key: TS-1633 URL: https://issues.apache.org/jira/browse/TS-1633 Project: Traffic Server Issue Type: New Feature Components: Metrics Reporter: Yakov Kopel Assignee: Uri Shachar Priority: Minor Fix For: sometime Attachments: stat_max_ver_1.diff Adding a new stat sync type - max. This is a good type of stat to find peaks in the stats. It can be very useful with the stat clear api (after the fix - TS-1631). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1666) Plugins, clustering and core crashes when share_server_sessions=2
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1666:
---
Assignee: Leif Hedstrom
Plugins, clustering and core crashes when share_server_sessions=2
-
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Assignee: Leif Hedstrom
Priority: Critical
Labels: Crash
Fix For: 5.1.0
ibrezac dumped this trace on irc:
{noformat}
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
{noformat}
configuration used:
{noformat}
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
{noformat}
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
{noformat}
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1590) use_remap_processor crashes if share_server_sessions = 2
[
https://issues.apache.org/jira/browse/TS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1590:
---
Assignee: Leif Hedstrom (was: Bryan Call)
use_remap_processor crashes if share_server_sessions = 2
Key: TS-1590
URL: https://issues.apache.org/jira/browse/TS-1590
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.0
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
Labels: Crash
Fix For: 5.1.0
easy to reproduce:
{code}
CONFIG proxy.config.remap.use_remap_processor INT 1 (default is 0)
CONFIG proxy.config.http.share_server_sessions INT 2 (0, 1 will be ok)
{code}
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1210
[Switching to process 8927 thread 0x1a03]
0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
(gdb) bt
#0 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
#1 0x0001000eb366 in HttpSessionManager::acquire_session
(this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19
127.0.0.1, ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
#2 0x000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0,
raw=false) at HttpSM.cc:4384
..
(gdb) p this_ethread()-l1_hash
$2 = (SessionBucket *) 0x0
(gdb) p this_ethread()-event_types
$3 = 2 (ET_REMAP)
{code}
Using separate remap processor is a hidden option, and I enable it by
accident.. (Does anyone use it in prod?)
I noticed HttpSM::do_http_server_open is always executed by the remap
processer ethread (because of
action.continuation-handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if
wrong). While the remap thread was not initialized as ET_NET and has no
l1_hash, server session lookup in this ET_REMAP thread will crash.
I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on
ET_NET. So a fast workaround would be falling back to global server
connection when use_remap_processor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1666) Plugins, clustering and core crashes when share_server_sessions=2
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1666:
---
Fix Version/s: (was: 5.0.0)
5.1.0
Plugins, clustering and core crashes when share_server_sessions=2
-
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Priority: Critical
Labels: Crash
Fix For: 5.1.0
ibrezac dumped this trace on irc:
{noformat}
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
{noformat}
configuration used:
{noformat}
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
{noformat}
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
{noformat}
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1590) use_remap_processor crashes if share_server_sessions = 2
[
https://issues.apache.org/jira/browse/TS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1590:
---
Fix Version/s: (was: 5.0.0)
5.1.0
use_remap_processor crashes if share_server_sessions = 2
Key: TS-1590
URL: https://issues.apache.org/jira/browse/TS-1590
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.0
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
Labels: Crash
Fix For: 5.1.0
easy to reproduce:
{code}
CONFIG proxy.config.remap.use_remap_processor INT 1 (default is 0)
CONFIG proxy.config.http.share_server_sessions INT 2 (0, 1 will be ok)
{code}
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1210
[Switching to process 8927 thread 0x1a03]
0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
(gdb) bt
#0 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
#1 0x0001000eb366 in HttpSessionManager::acquire_session
(this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19
127.0.0.1, ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
#2 0x000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0,
raw=false) at HttpSM.cc:4384
..
(gdb) p this_ethread()-l1_hash
$2 = (SessionBucket *) 0x0
(gdb) p this_ethread()-event_types
$3 = 2 (ET_REMAP)
{code}
Using separate remap processor is a hidden option, and I enable it by
accident.. (Does anyone use it in prod?)
I noticed HttpSM::do_http_server_open is always executed by the remap
processer ethread (because of
action.continuation-handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if
wrong). While the remap thread was not initialized as ET_NET and has no
l1_hash, server session lookup in this ET_REMAP thread will crash.
I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on
ET_NET. So a fast workaround would be falling back to global server
connection when use_remap_processor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1757:
---
Fix Version/s: (was: 5.0.0)
5.1.0
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: Yunkai Zhang
Labels: A, crash, review
Fix For: 5.1.0
Attachments: 0001-TS-1757-workaround-to-fix-core-at-escapify_url.patch
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1776) Range requests not working right
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1776: --- Fix Version/s: (was: 5.0.0) 5.1.0 Range requests not working right Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell Assignee: Alan M. Carroll Priority: Blocker Fix For: 5.1.0 With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1822) Do we still need proxy.config.system.mmap_max ?
[ https://issues.apache.org/jira/browse/TS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1822: --- Fix Version/s: (was: 5.0.0) sometime Do we still need proxy.config.system.mmap_max ? --- Key: TS-1822 URL: https://issues.apache.org/jira/browse/TS-1822 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: James Peach Fix For: sometime A long time ago, we added proxy.config.system.mmap_max to let the traffic_server increase the max number of mmap segments that we want to use. We currently set this to 2MM. I'm wondering, do we really need this still ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1800) coalesce FNV hash implementations
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001905#comment-14001905 ] Bryan Call commented on TS-1800: [~psudaemon] Do you think you will land this in the next week? If not please move to 5.1 release. coalesce FNV hash implementations - Key: TS-1800 URL: https://issues.apache.org/jira/browse/TS-1800 Project: Traffic Server Issue Type: Bug Components: Core Reporter: James Peach Assignee: Phil Sorber Fix For: 5.0.0 We have 4 copies of the FNV hash function: example/query-remap/query-remap.c iocore/hostdb/I_HostDBProcessor.h proxy/hdrs/HdrToken.cc proxy/logstats.cc We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1866) Clean up some of the unsupported hardware architecture tests in configure.ac
[
https://issues.apache.org/jira/browse/TS-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001910#comment-14001910
]
Leif Hedstrom commented on TS-1866:
---
For example
{code}
*sparc*)
cpu_architecture=-march=ultrasparc
{code}
Clean up some of the unsupported hardware architecture tests in configure.ac
Key: TS-1866
URL: https://issues.apache.org/jira/browse/TS-1866
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1883) SSL origin connections do not support connection timeouts
[
https://issues.apache.org/jira/browse/TS-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1883:
---
Fix Version/s: (was: 5.0.0)
5.1.0
SSL origin connections do not support connection timeouts
-
Key: TS-1883
URL: https://issues.apache.org/jira/browse/TS-1883
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: James Peach
Fix For: 5.1.0
In {{proxy/http/HttpSM.cc}}, we can see that origin connections do not
support timeouts if the scheme is HTTPS:
{code}
void
HttpSM::do_http_server_open(bool raw)
{
...
if (t_state.scheme == URL_WKSIDX_HTTPS) {
DebugSM(http, calling sslNetProcessor.connect_re);
connect_action_handle = sslNetProcessor.connect_re(this,// state
machine
t_state.current.server-addr.sa,// addr + port
opt);
} else {
...
// Setup the timeouts
// Set the inactivity timeout to the connect timeout so that we
// we fail this server if it doesn't start sending the response
// header
MgmtInt connect_timeout;
if (t_state.method == HTTP_WKSIDX_POST || t_state.method ==
HTTP_WKSIDX_PUT) {
connect_timeout = t_state.txn_conf-post_connect_attempts_timeout;
} else if (t_state.current.server == t_state.parent_info) {
connect_timeout = t_state.http_config_param-parent_connect_timeout;
} else {
if (t_state.pCongestionEntry != NULL)
connect_timeout = t_state.pCongestionEntry-connect_timeout();
else
connect_timeout = t_state.txn_conf-connect_attempts_timeout;
}
DebugSM(http, calling netProcessor.connect_s);
connect_action_handle = netProcessor.connect_s(this, // state
machine
t_state.current.server-addr.sa,// addr + port
connect_timeout, opt);
...
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1776) Range requests not working right
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1776: --- Fix Version/s: (was: 5.1.0) sometime Range requests not working right Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell Assignee: Alan M. Carroll Priority: Blocker Fix For: sometime With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001919#comment-14001919
]
Bryan Call commented on TS-1917:
[~jpe...@apache.org]
Any updates on this?
It seems that one of assert in HttpTransact::handle_content_length_header()
is unnecessary
---
Key: TS-1917
URL: https://issues.apache.org/jira/browse/TS-1917
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Yunkai Zhang
Assignee: James Peach
Labels: review
Fix For: 5.0.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`,
ap=0x2b34979073a0) at ink_error.cc:65
#4 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
OK) at HttpTransact.cc:7731
#8 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
By analyzing the code, it seems that this assertion is unnecessary:
When client sends a request to ATS, and the content hits in cache, but if the
cache is STALE, ATS will sent a request to Original-Server.
In this case, the t_sate.source will be updated to
SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
HttpTransact::handle_cache_operation_on_forward_server_response()
= s-state_machine-do_range_setup_if_necessary(),
[jira] [Updated] (TS-1933) Uninformative warnings from traffic_manager on startup
[
https://issues.apache.org/jira/browse/TS-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1933:
---
Fix Version/s: (was: 5.0.0)
5.2.0
Uninformative warnings from traffic_manager on startup
--
Key: TS-1933
URL: https://issues.apache.org/jira/browse/TS-1933
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.2.0
During startup, traffic_manager always seems to produce these errors:
{code}
[Jun 1 14:59:46.577] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
Cleaning up and reissuing signal #2
[Jun 1 14:59:46.578] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
signal #2
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
{code}
They seem harmless, but annoying.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001897#comment-14001897
]
Bryan Call commented on TS-1757:
We should really have a state variable instead of relying on milestones.
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: Yunkai Zhang
Labels: A, crash, review
Fix For: 5.1.0
Attachments: 0001-TS-1757-workaround-to-fix-core-at-escapify_url.patch
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1979) Investigate body factory and its use of malloc()
[ https://issues.apache.org/jira/browse/TS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1979: --- Fix Version/s: (was: 5.0.0) 5.1.0 Investigate body factory and its use of malloc() Key: TS-1979 URL: https://issues.apache.org/jira/browse/TS-1979 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.1.0 It might be a nice optimization to make it use heap allocation (that is, put the body factory on the freelist) for small bodies. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1967) create max accept handler function
[ https://issues.apache.org/jira/browse/TS-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1967: --- Fix Version/s: (was: 5.0.0) 5.1.0 create max accept handler function --- Key: TS-1967 URL: https://issues.apache.org/jira/browse/TS-1967 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.2.4 Reporter: Bin Chen Assignee: Bin Chen Labels: review Fix For: 5.1.0 Attachments: TS-1967.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-1979) Investigate body factory and its use of malloc()
[ https://issues.apache.org/jira/browse/TS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13907688#comment-13907688 ] Leif Hedstrom edited comment on TS-1979 at 5/19/14 3:52 PM: Overall, the code is pretty suboptimal, with repeatedly reparsing/processing of format strings etc. was (Author: zwoop): Overall, the code is pretty suboptimal, with repeated reparsing/processing of format strings etc. Investigate body factory and its use of malloc() Key: TS-1979 URL: https://issues.apache.org/jira/browse/TS-1979 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.1.0 It might be a nice optimization to make it use heap allocation (that is, put the body factory on the freelist) for small bodies. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1981) Url remap method filtering is broken with invalid method
[
https://issues.apache.org/jira/browse/TS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001926#comment-14001926
]
Bryan Call commented on TS-1981:
[~amc]
Any updates on this?
Url remap method filtering is broken with invalid method
Key: TS-1981
URL: https://issues.apache.org/jira/browse/TS-1981
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Security
Reporter: Thach Tran
Assignee: Alan M. Carroll
Labels: review
Fix For: 5.0.0
Attachments:
0001-TS-1981-Fix-method-filtering-to-deny-invalid-methods.patch,
updated-TS-1981.patch
ACL filtering based on HTTP's method is ignored if method received from
client is invalid.
To reproduce, with the default 8080 {{server_ports}} configure the
{{remap.conf}} as follows.
{noformat}
map http://localhost:8080/ http://www.google.com/ @method=GET
{noformat}
Then run the following curl command.
{noformat}
$ curl -v -X AA http://localhost:8080/
{noformat}
Notice that a 200 OK response is received by the client with some (empty)
HTML from google.com.
If the following curl command is issued instead
{noformat}
$ curl -v -X PUT http://localhost:8080/
{noformat}
One will see that TS sends back a 403 Access Denied as expected.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1983) ACL rules in remap.config does not take precedence over rules in ip_allow.config
[
https://issues.apache.org/jira/browse/TS-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1983:
---
Fix Version/s: (was: 5.0.0)
6.0.0
ACL rules in remap.config does not take precedence over rules in
ip_allow.config
Key: TS-1983
URL: https://issues.apache.org/jira/browse/TS-1983
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 6.0.0
Lets say you want to allow DELETE for a small sub-set of requests, based on
remap.config rules. The reasonable configuration is to do e.g.
{code}
map http://dav.example.com http://127.0.0.1 @method=DELETE @action=allow
{code}
However, this does not work, since the global DENY in ip_allow.config takes
precedence (it denies all DELETE's). This is actually sort of a regression I
think, it did not use to behave like this I'm fairly certain.
The workaround (which is incredibly cumbersom if you have even a moderately
large remap.config, is to inverse the rules. E.g.
{code}
src_ip=0.0.0.0-255.255.255.255action=ip_deny
method=PUSH|PURGE
{code}
and
{code}
map http://other.example.com http://123 @method=DELETE @action=deny
map http://another.example.com http://123 @method=DELETE @action=deny
map http://more.example.com http://123 @method=DELETE @action=deny
.
.
.
{code}
This kinda sucks to maintain, and also opens up a PEBKAC security problem,
when someone adds a new remap.config rule and forgets to deny the DELETEs.
I really feel that the ACLs from remap.config (if they match, you can specify
IP ranges etc. as well), should take precedence over ip_allow.config.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1992) examine mgmt/RecordsConfig.cc, add validation where it makes sense
[
https://issues.apache.org/jira/browse/TS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1992:
---
Fix Version/s: (was: 5.0.0)
5.1.0
examine mgmt/RecordsConfig.cc, add validation where it makes sense
--
Key: TS-1992
URL: https://issues.apache.org/jira/browse/TS-1992
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Fix For: 5.1.0
example:
{code}
{RECT_CONFIG, proxy.config.http.cache.required_headers, RECD_INT, 2,
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{code}
We should change this to
{code}
{RECT_CONFIG, proxy.config.http.cache.required_headers, RECD_INT, 2,
RECU_DYNAMIC, RR_NULL, RECC_NULL, [0-2], RECA_NULL}
{code}
which are the valid values for this config.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1983) ACL rules in remap.config does not take precedence over rules in ip_allow.config
[
https://issues.apache.org/jira/browse/TS-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001929#comment-14001929
]
Bryan Call commented on TS-1983:
Incompatible change that would require an major version.
ACL rules in remap.config does not take precedence over rules in
ip_allow.config
Key: TS-1983
URL: https://issues.apache.org/jira/browse/TS-1983
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 6.0.0
Lets say you want to allow DELETE for a small sub-set of requests, based on
remap.config rules. The reasonable configuration is to do e.g.
{code}
map http://dav.example.com http://127.0.0.1 @method=DELETE @action=allow
{code}
However, this does not work, since the global DENY in ip_allow.config takes
precedence (it denies all DELETE's). This is actually sort of a regression I
think, it did not use to behave like this I'm fairly certain.
The workaround (which is incredibly cumbersom if you have even a moderately
large remap.config, is to inverse the rules. E.g.
{code}
src_ip=0.0.0.0-255.255.255.255action=ip_deny
method=PUSH|PURGE
{code}
and
{code}
map http://other.example.com http://123 @method=DELETE @action=deny
map http://another.example.com http://123 @method=DELETE @action=deny
map http://more.example.com http://123 @method=DELETE @action=deny
.
.
.
{code}
This kinda sucks to maintain, and also opens up a PEBKAC security problem,
when someone adds a new remap.config rule and forgets to deny the DELETEs.
I really feel that the ACLs from remap.config (if they match, you can specify
IP ranges etc. as well), should take precedence over ip_allow.config.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-2810) add TSVConnFdCreate API
[
https://issues.apache.org/jira/browse/TS-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach closed TS-2810.
---
Resolution: Fixed
add TSVConnFdCreate API
---
Key: TS-2810
URL: https://issues.apache.org/jira/browse/TS-2810
Project: Traffic Server
Issue Type: Bug
Components: Core, TS API
Reporter: James Peach
Assignee: James Peach
Labels: api-change
Fix For: 5.0.0
Add a new API {{TSVConnFdCreate}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2810) add TSVConnFdCreate API
[
https://issues.apache.org/jira/browse/TS-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001951#comment-14001951
]
ASF subversion and git services commented on TS-2810:
-
Commit 442defed1982f67eaffe4b4e1389c23f6ab25bdd in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=442defe ]
TS-2810: add TSVConnFdCreate API
Add a new TSVConnFdCreate API that binds a connected socket to a TSVConn.
add TSVConnFdCreate API
---
Key: TS-2810
URL: https://issues.apache.org/jira/browse/TS-2810
Project: Traffic Server
Issue Type: Bug
Components: Core, TS API
Reporter: James Peach
Assignee: James Peach
Labels: api-change
Fix For: 5.0.0
Add a new API {{TSVConnFdCreate}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001966#comment-14001966
]
James Peach commented on TS-1917:
-
Nope. Not sure whether I will get to this by 5.0.
It seems that one of assert in HttpTransact::handle_content_length_header()
is unnecessary
---
Key: TS-1917
URL: https://issues.apache.org/jira/browse/TS-1917
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Yunkai Zhang
Assignee: James Peach
Labels: review
Fix For: 5.0.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`,
ap=0x2b34979073a0) at ink_error.cc:65
#4 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
OK) at HttpTransact.cc:7731
#8 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
By analyzing the code, it seems that this assertion is unnecessary:
When client sends a request to ATS, and the content hits in cache, but if the
cache is STALE, ATS will sent a request to Original-Server.
In this case, the t_sate.source will be updated to
SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
HttpTransact::handle_cache_operation_on_forward_server_response()
=
[jira] [Commented] (TS-2812) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility
[ https://issues.apache.org/jira/browse/TS-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001968#comment-14001968 ] James Peach commented on TS-2812: - I'm suggesting that the plugin is superfluous, since the root cause is probably a bug. AFAIK, the HTTP/2 does not speak to what a gateway should do when translating from HTTP/2 to HTTP/1. I could see that sometime in the future something like this plugin could be needed/ header_normalize to convert lower case spdy hdrs to camel case for backward compatibility - Key: TS-2812 URL: https://issues.apache.org/jira/browse/TS-2812 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2812.diff During our SPDY testing, we observed that certain legacy systems are not able to handle lower case hdrs mandated by SPDY (and even http 1.0). This simple plugin converts the lowercase header names into camel case and could be used as an interim solution until the legacy systems are upgraded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2056) When proxy.config.http.negative_caching_enabled = 1 we cache errors even if Cache-Control: no-cache is sent from the origin
[
https://issues.apache.org/jira/browse/TS-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2056:
---
Assignee: (was: Bryan Call)
When proxy.config.http.negative_caching_enabled = 1 we cache errors even if
Cache-Control: no-cache is sent from the origin
---
Key: TS-2056
URL: https://issues.apache.org/jira/browse/TS-2056
Project: Traffic Server
Issue Type: Bug
Reporter: Phil Sorber
Labels: C
Fix For: 5.1.0
{noformat}
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Cache-Control: no-cache
Date: Sun, 21 Jul 2013 17:20:00 GMT
Expires: Sun, 21 Jul 2013 17:50:00 GMT
Age: 38
Content-Length: 40
Connection: keep-alive
Via: http/1.1 XX (ApacheTrafficServer/3.3.5-dev [uScHs f p eN:t cCHi
p s ])
Server: ATS/3.3.5-dev
{noformat}
While this is a grey area since we are already breaking the spec by negative
caching, I think we should still not cache this when explicitly told not to
by the origin and [~zwoop] agrees!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2056) When proxy.config.http.negative_caching_enabled = 1 we cache errors even if Cache-Control: no-cache is sent from the origin
[
https://issues.apache.org/jira/browse/TS-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2056:
---
Fix Version/s: (was: 5.0.0)
5.1.0
When proxy.config.http.negative_caching_enabled = 1 we cache errors even if
Cache-Control: no-cache is sent from the origin
---
Key: TS-2056
URL: https://issues.apache.org/jira/browse/TS-2056
Project: Traffic Server
Issue Type: Bug
Reporter: Phil Sorber
Labels: C
Fix For: 5.1.0
{noformat}
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Cache-Control: no-cache
Date: Sun, 21 Jul 2013 17:20:00 GMT
Expires: Sun, 21 Jul 2013 17:50:00 GMT
Age: 38
Content-Length: 40
Connection: keep-alive
Via: http/1.1 XX (ApacheTrafficServer/3.3.5-dev [uScHs f p eN:t cCHi
p s ])
Server: ATS/3.3.5-dev
{noformat}
While this is a grey area since we are already breaking the spec by negative
caching, I think we should still not cache this when explicitly told not to
by the origin and [~zwoop] agrees!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2058) Traffic server fails to start with lots of SNI ssl certs defined
[ https://issues.apache.org/jira/browse/TS-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2058: --- Fix Version/s: (was: 5.0.0) sometime Traffic server fails to start with lots of SNI ssl certs defined Key: TS-2058 URL: https://issues.apache.org/jira/browse/TS-2058 Project: Traffic Server Issue Type: Bug Components: Performance, SSL Reporter: Kris Lindgren Assignee: James Peach Fix For: sometime Attachments: TS-2058-hacked-up.diff Running into an issue with SNI under 3.2.4 - with 100k ssl certs defined in ssl_multicert.config with the following format: ssl_cert_name=cert Traffic server will never start. It looks like it keeps getting killed by traffic_cop. It looks like succesfull startup will take ~2minutes for 100k ssl certs on my machine and about 15 seconds for 40k ssl certs. I would like to try to get to one million ssl certs defined with traffic server able to start successfully. Anything that could be done to increase the speed and allow that amount of SSL certs defined to start successfully would be much appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2062) LogHost orphaned log does not honor log-buffer configs
[
https://issues.apache.org/jira/browse/TS-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2062:
---
Fix Version/s: (was: 5.1.0)
5.2.0
LogHost orphaned log does not honor log-buffer configs
--
Key: TS-2062
URL: https://issues.apache.org/jira/browse/TS-2062
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: A
Fix For: 5.2.0
It looks like when we setup remote logging, the LogHost orphan log is always
created with the default configurations (9216 bytes). This ignores e.g.
{code}
proxy.config.log.log_buffer_size
proxy.config.log.max_line_size
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2062) LogHost orphaned log does not honor log-buffer configs
[
https://issues.apache.org/jira/browse/TS-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2062:
---
Fix Version/s: (was: 5.0.0)
5.1.0
LogHost orphaned log does not honor log-buffer configs
--
Key: TS-2062
URL: https://issues.apache.org/jira/browse/TS-2062
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: A
Fix For: 5.2.0
It looks like when we setup remote logging, the LogHost orphan log is always
created with the default configurations (9216 bytes). This ignores e.g.
{code}
proxy.config.log.log_buffer_size
proxy.config.log.max_line_size
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2080) Remove arbitrary 1 year max cache freshness limit
[
https://issues.apache.org/jira/browse/TS-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2080:
---
Fix Version/s: (was: 5.0.0)
sometime
Remove arbitrary 1 year max cache freshness limit
-
Key: TS-2080
URL: https://issues.apache.org/jira/browse/TS-2080
Project: Traffic Server
Issue Type: Improvement
Components: Cache
Reporter: Leif Hedstrom
Fix For: sometime
For some reason (maybe john know's ?) we have an upper limit on cache
freshness at 1 year. I have no idea why this is, the only place it's used is
in HttpTransact.cc:
{code}
max_freshness_bounds = min((MgmtInt)NUM_SECONDS_IN_ONE_YEAR,
s-txn_conf-cache_guaranteed_max_lifetime);
{code}
Begs the question, why not just remove the min(), and always use the
cache_guranteed_max_lifetime? This is a records.config setting, defaults to a
1 year (go figure).
{code}
{RECT_CONFIG, proxy.config.http.cache.guaranteed_max_lifetime, RECD_INT,
31536000, RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2095:
--
Assignee: Bryan Call (was: James Peach)
autoconf warnings related to unordered_map
--
Key: TS-2095
URL: https://issues.apache.org/jira/browse/TS-2095
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.0.0
{code}
configure: WARNING: unordered_map: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_map: proceeding with the compiler's result
checking for unordered_map... yes
checking unordered_set usability... yes
checking unordered_set presence... no
configure: WARNING: unordered_set: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_set: proceeding with the compiler's result
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2098) Memory leak with reloading SSL certificates 3.3.4
[ https://issues.apache.org/jira/browse/TS-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001990#comment-14001990 ] Bryan Call commented on TS-2098: [~klindgren] Can you please reply to James comment or we will close the bug because we can't reproduce Memory leak with reloading SSL certificates 3.3.4 - Key: TS-2098 URL: https://issues.apache.org/jira/browse/TS-2098 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.3.4 Reporter: Kris Lindgren Assignee: James Peach Priority: Blocker Fix For: 5.0.0 Attachments: assert.diff When using the new feature of 3.3.4 to re-read the ssl configuration without restart the old memory that the configuration uses is not released. I have ~220k ssl certs defined which consumes ~1.2gb of memory. If I add/remove a single ssl cert from ssl_multicert.config and reload via traffic_line -x memory usage increases from 1.2gb to 2.4gb and stays there. If I make another change and reload again via traffic_line -x, memory usage jumps to 3.6gb and stays there. It appears that after successfully loading the new configuration into memory the old configuration is never purged. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2098) Memory leak with reloading SSL certificates 3.3.4
[ https://issues.apache.org/jira/browse/TS-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2098: --- Fix Version/s: (was: sometime) 5.0.0 Memory leak with reloading SSL certificates 3.3.4 - Key: TS-2098 URL: https://issues.apache.org/jira/browse/TS-2098 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.3.4 Reporter: Kris Lindgren Assignee: James Peach Priority: Blocker Fix For: 5.0.0 Attachments: assert.diff When using the new feature of 3.3.4 to re-read the ssl configuration without restart the old memory that the configuration uses is not released. I have ~220k ssl certs defined which consumes ~1.2gb of memory. If I add/remove a single ssl cert from ssl_multicert.config and reload via traffic_line -x memory usage increases from 1.2gb to 2.4gb and stays there. If I make another change and reload again via traffic_line -x, memory usage jumps to 3.6gb and stays there. It appears that after successfully loading the new configuration into memory the old configuration is never purged. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2098) Memory leak with reloading SSL certificates 3.3.4
[ https://issues.apache.org/jira/browse/TS-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2098: --- Fix Version/s: (was: 5.0.0) sometime Memory leak with reloading SSL certificates 3.3.4 - Key: TS-2098 URL: https://issues.apache.org/jira/browse/TS-2098 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.3.4 Reporter: Kris Lindgren Assignee: James Peach Priority: Blocker Fix For: 5.0.0 Attachments: assert.diff When using the new feature of 3.3.4 to re-read the ssl configuration without restart the old memory that the configuration uses is not released. I have ~220k ssl certs defined which consumes ~1.2gb of memory. If I add/remove a single ssl cert from ssl_multicert.config and reload via traffic_line -x memory usage increases from 1.2gb to 2.4gb and stays there. If I make another change and reload again via traffic_line -x, memory usage jumps to 3.6gb and stays there. It appears that after successfully loading the new configuration into memory the old configuration is never purged. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2150) Add Milestone log tags
[
https://issues.apache.org/jira/browse/TS-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2150:
---
Fix Version/s: (was: 5.0.0)
sometime
Add Milestone log tags
--
Key: TS-2150
URL: https://issues.apache.org/jira/browse/TS-2150
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Leif Hedstrom
Fix For: sometime
We have a notion of milestones in the core, and plugin APIs
(TSHttpTxnMilestoneGet() ). It'd be useful to expose these milestone timers
as a log tag, something like:
{code}
%{UA_BEGIN}mtms
{code}
mtms is just an example / suggestion, MilestoneTimeMilliSecond, we can make
it whatever we like.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2182) Setting proxy.config.net.sock_recv_buffer_size_out seriously affects performance
[
https://issues.apache.org/jira/browse/TS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2182:
---
Assignee: Leif Hedstrom
Setting proxy.config.net.sock_recv_buffer_size_out seriously affects
performance
Key: TS-2182
URL: https://issues.apache.org/jira/browse/TS-2182
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Network
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
I still need to do some more testing, but setting
{code}
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 256K
{code}
on my box reduces throughput to a (fast, local) Origin by about 1000x.
Throughput went from 18MB/sec to 15KB/sec. Removing this setting, restored
normal performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2182) Setting proxy.config.net.sock_recv_buffer_size_out seriously affects performance
[
https://issues.apache.org/jira/browse/TS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001999#comment-14001999
]
Bryan Call commented on TS-2182:
[~zwoop]
Please verify...
Setting proxy.config.net.sock_recv_buffer_size_out seriously affects
performance
Key: TS-2182
URL: https://issues.apache.org/jira/browse/TS-2182
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Network
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
I still need to do some more testing, but setting
{code}
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 256K
{code}
on my box reduces throughput to a (fast, local) Origin by about 1000x.
Throughput went from 18MB/sec to 15KB/sec. Removing this setting, restored
normal performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2110) Cleanup ts/experimental.h
[ https://issues.apache.org/jira/browse/TS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001993#comment-14001993 ] Bryan Call commented on TS-2110: [~kichan] Can you get this done in the next week for the 5.0 release? Cleanup ts/experimental.h - Key: TS-2110 URL: https://issues.apache.org/jira/browse/TS-2110 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Kit Chan Labels: api-change Fix For: 5.0.0 We should go through the APIs in experimental.h, and do one of 1. Remove 2. Move to ts/ts.h.in 3. Leave as is, assuming it's still considered experimental. I know there are arguments for and against having an experimental.h include file. I guess I don't have a strong opinion, another solution is to simply keep everything in ts.h.in, but mark APIs that are experimental as such. I do believe having APIs in an experimental state has benefits (such as we can modify such APIs as we see fit, there is no ABI/API compatibility promise). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2186) Promote TSHttpTxnOverwriteExpireTime() to ts/ts.h
[ https://issues.apache.org/jira/browse/TS-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-2186. -- Resolution: Fixed Move this api when cleaning up experimental Promote TSHttpTxnOverwriteExpireTime() to ts/ts.h - Key: TS-2186 URL: https://issues.apache.org/jira/browse/TS-2186 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 5.0.0 It is currently in ts/experimental.h -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2218) create a standard way of getting the plugin configuration directory
[ https://issues.apache.org/jira/browse/TS-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2218: --- Fix Version/s: (was: 5.0.0) create a standard way of getting the plugin configuration directory --- Key: TS-2218 URL: https://issues.apache.org/jira/browse/TS-2218 Project: Traffic Server Issue Type: Improvement Components: Configuration, Plugins Reporter: Bryan Call Assignee: Bryan Call Labels: api-change Currently some plugins use TSPluginDirGet() (/usr/local/libexec/trafficserver) and some have hard coded paths for getting the directory where the config files are set. I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in config.layout and is /usr/local/etc by default) as the default base directory for the plugin configuration. Under this directory people will have their config file or a sub directory if there are a lot of config files for a plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/) There will be an API to get the plugin config directory called TSPluginConfigDir() and this will by default pass back sysconfdir/trafficserver/plugins/. All plugins will use this API to get the configuration directory. There will also be a records.config option to override the default plugin config directory. This option will be called proxy.config.plugin.plugin_config_dir. This option will be set to NULL by default and the API will assume sysconfdir/trafficsever/plugins by default. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2224) We leave an .../etc/trafficserver/snapshots directory behind, empty
[ https://issues.apache.org/jira/browse/TS-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2224: --- Assignee: (was: Leif Hedstrom) We leave an .../etc/trafficserver/snapshots directory behind, empty --- Key: TS-2224 URL: https://issues.apache.org/jira/browse/TS-2224 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Fix For: sometime Snapshots goes into the .../var/trafficserver directory, yet we still have make install create this writeable directory under etc/trafficserver. We should fix / remove this. At the same time, lets make sure the records.config configuration for snapshots dir actually works as expected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2231) header_rewrite uses boost regexes, we should switch to PCRE
[ https://issues.apache.org/jira/browse/TS-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2231: --- Fix Version/s: (was: 5.0.0) 5.1.0 header_rewrite uses boost regexes, we should switch to PCRE --- Key: TS-2231 URL: https://issues.apache.org/jira/browse/TS-2231 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 It makes no sense to have another regex format, lets unify everything on PCRE. Also, while we're at it, lets get rid of BOOST entirely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2231) header_rewrite uses boost regexes, we should switch to PCRE
[ https://issues.apache.org/jira/browse/TS-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2231: --- Fix Version/s: (was: 5.1.0) 5.0.0 header_rewrite uses boost regexes, we should switch to PCRE --- Key: TS-2231 URL: https://issues.apache.org/jira/browse/TS-2231 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 It makes no sense to have another regex format, lets unify everything on PCRE. Also, while we're at it, lets get rid of BOOST entirely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2224) We leave an .../etc/trafficserver/snapshots directory behind, empty
[ https://issues.apache.org/jira/browse/TS-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2224: --- Fix Version/s: (was: 5.0.0) sometime We leave an .../etc/trafficserver/snapshots directory behind, empty --- Key: TS-2224 URL: https://issues.apache.org/jira/browse/TS-2224 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: sometime Snapshots goes into the .../var/trafficserver directory, yet we still have make install create this writeable directory under etc/trafficserver. We should fix / remove this. At the same time, lets make sure the records.config configuration for snapshots dir actually works as expected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2237) URL encoding wrong in squid.blog
[ https://issues.apache.org/jira/browse/TS-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2237: --- Fix Version/s: (was: 5.0.0) 5.1.0 URL encoding wrong in squid.blog Key: TS-2237 URL: https://issues.apache.org/jira/browse/TS-2237 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: David Carlin Priority: Minor Fix For: 5.1.0 I was replaying URLs captured from squid.blog and I noticed I was getting 404's for some of them when squid.blog showed a 200 for that request. Turns out there is an issue with URL encoding. For example: Requesting file 'duck%20sports%20authority.gif' via curl will put this in the logs: duck%2520sports%2520authority.gif The % from %20 (space) in the request is being converted to %25 resulting in %2520 I tested both the %cquc and %cquuc log fields - same thing happens. I tested on ATS 3.2.0 and 3.3.5 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2253: -- Assignee: Bryan Call (was: weijin) PluginVC::process_close Segmentation fault --- Key: TS-2253 URL: https://issues.apache.org/jira/browse/TS-2253 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.0.1 Reporter: bettydramit Assignee: Bryan Call Labels: crash, review Fix For: 5.0.0 Attachments: 4.0.1.patch, TS-2253.wj.diff Env: centos 6 x86_64 ats 4.0.1 [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] [0x2b7b3e825ac0] gdb info Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. done. Loaded symbols for /lib64/libnss_dns-2.12.so Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. Program terminated with signal 11, Segmentation fault. #0 0x2ac40034ed80 in ?? () Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 (gdb) where #0 0x2ac40034ed80 in ?? () #1 0x004d1ef2 in PluginVC::process_close() () #2 0x004d2938 in PluginVC::main_handler(int, void*) () #3 0x006a372f in EThread::process_event(Event*, int) () #4 0x006a42ab in EThread::execute() () #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2153) traffic_manager -tsArgs doesn't work
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2153:
--
Fix Version/s: (was: 5.0.0)
sometime
traffic_manager -tsArgs doesn't work
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Adam Twardowski
Fix For: sometime
traffic_manager -tsArgs -T 'log.*'
Running the above command on the 4.0.0 branch commit
c8931df15e33924bb459d40859a0b49331a6dbaf
resulted in no running traffic_server and the following ps output
nobody 16807 0.1 0.9 410884 18272 pts/0Sl+ 16:58 0:00
traffic_manager -tsArgs -T log.*
nobody 16816 0.0 0.0 0 0 pts/0Z+ 16:58 0:00
[traffic_manager] defunct
root 16818 0.0 0.0 103240 864 pts/1S+ 16:59 0:00 grep tr
manger.log output
--
[Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server
Args: ' -T log.*'
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup
complete
[Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE:
[LocalManager::startProxy] Launching ts process
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:
[LocalManager::startProxy] ts options must contain -M
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: (last system error 0:
Success)
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2258) Verify that all fields are correct in RecordsConfig.cc
[ https://issues.apache.org/jira/browse/TS-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2258: --- Fix Version/s: (was: 5.0.0) 5.1.0 Verify that all fields are correct in RecordsConfig.cc -- Key: TS-2258 URL: https://issues.apache.org/jira/browse/TS-2258 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Fix For: 5.1.0 We should go through every configuration in RecordsConfig.cc, and assure that fields such as if it's dynamically reloadable or not, validation regexes etc. are all set 100% correct. Once this file is accurate, and will be the one true authoritative source for everything configuration; it can be used for command line help (e.g. traffic_line can say if a config is reloadable), and we can even use it as a source for the Sphinx documentation. A bonus would be to add a one-line helper line for each configuration in RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new type of tools to help managing configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager
[ https://issues.apache.org/jira/browse/TS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002032#comment-14002032 ] Bryan Call commented on TS-2268: [~ushachar] What do you want to do with this ticket? Add support for opening protocol traffic sockets through the traffic_manager Key: TS-2268 URL: https://issues.apache.org/jira/browse/TS-2268 Project: Traffic Server Issue Type: Improvement Components: Plugins, TS API Reporter: Uri Shachar Assignee: Uri Shachar Labels: api-addition Fix For: 5.0.0 Add a TSNetAcceptNamedDescriptor(contp, char *) function to allow a protocol plugin to set a callback for accepting new connections on a socket opened by the traffic_manager (that's defined like 2345:plugin:name=myname in the server_ports configuration). This has three advantages on opening a socket using TSNetAccept: 1) If the traffic_server crashes and restarts, new connections won't be rejected while we recover - This is the main selling point of the new API. 2) Support for all port configuration flags (Which also exists when using TSPortDescriptorAccept) 3) Allow for a single point of configuration for all ATS ports -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2289) Only support AIO_MODE_THREAD and AIO_MODE_NATIVE
[ https://issues.apache.org/jira/browse/TS-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2289: --- Fix Version/s: (was: 5.0.0) 5.1.0 Only support AIO_MODE_THREAD and AIO_MODE_NATIVE Key: TS-2289 URL: https://issues.apache.org/jira/browse/TS-2289 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.1.0 As discussed, we'd like to simplify this code, and only keep our own AIO and the linux native AIO implementations. That would leave AIO_MODE_THREAD and AIO_MODE_NATIVE. Also, I think it's pretty unfortunate that AIO_MODE_NATIVE has to escape encapsulation and have custom code in e.g. Cache.cc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002036#comment-14002036 ] Bryan Call commented on TS-2274: Also look at the default SSL settings... Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2819) Add configuration and APIs to disable loop detection
Bryan Call created TS-2819: -- Summary: Add configuration and APIs to disable loop detection Key: TS-2819 URL: https://issues.apache.org/jira/browse/TS-2819 Project: Traffic Server Issue Type: Improvement Components: Configuration, HTTP Reporter: Bryan Call -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2298) 400 Multi-Hop Cycle detected with .insert_request_via_str
[
https://issues.apache.org/jira/browse/TS-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-2298.
--
Resolution: Invalid
Fix Version/s: (was: 5.0.0)
This is the normal behavior of ATS. You can remove the Via header on the
Apache httpd host or disable adding the via header for the remap rule.
I opened another ticket to add a configuration option to disable loop detection.
400 Multi-Hop Cycle detected with .insert_request_via_str
-
Key: TS-2298
URL: https://issues.apache.org/jira/browse/TS-2298
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.2.5, 4.0.2
Environment: RHEL6, x86_64, apache httpd, mod_proxy
Reporter: Jan-Frode Myklebust
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem
on both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map http://api.example.com http://api1.example.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
http://api.example.com:
{noformat}
ProxyPass /api/menu http://api.example.com/test/api/menu
{noformat}
If www.example.com and api.example.com is going trough the same
trafficserver with proxy.config.http.insert_request_via_str enabled we get
the Multi-Hop Cycle detected error. If they are going trough different
physical hosts, or if we disable proxy.config.http.insert_request_via_str
then the problem goes away.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2299:
---
Fix Version/s: (was: 5.0.0)
5.1.0
ATS seg faults in MIMEScanner::mime_scanner_get
---
Key: TS-2299
URL: https://issues.apache.org/jira/browse/TS-2299
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, MIME
Affects Versions: 4.0.1
Environment: RHEL 5.9
Reporter: John Paul Vasicek
Labels: Crash
Fix For: 5.1.0
I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2aafe810683d]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
(demangled)
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/lib64/libpthread.so.0[0x2ba86e67aca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x39f)[0x4d37cf]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8Plu
ginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x238)[0x6cb258]
/usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2ba86e67283d]
/usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x46e)[0x4d389e]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-2307. -- Resolution: Invalid Fix Version/s: (was: 5.0.0) Entity tags should be quoted according to http://www.ietf.org/rfc/rfc2616.txt (section 3.11). Range request with If-Range does not work - Key: TS-2307 URL: https://issues.apache.org/jira/browse/TS-2307 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.5, 4.0.1, 4.0.2 Reporter: Jungwoo Lee Labels: A 1. Precondition - Upload file such as video or music file on Origin server - On Chrome, access to the content file - Repeat followings -- Delete the cache of Chrome -- Refresh( press F5 ) 2. Result - Chrome does not play the content. 3. Cause - When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) -- if (!if_value || if_value[0] == '' || (comma_sep_list_len 1 if_value[1] == '/')) --- when ETAG doesn't start and end with this condition will be failed. -- The if_value points the string of value of If-Range 4. Expected Behaviour - Video and music file will be played in all the time on all case. -- When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2308) includedir in config.layout is not used
[ https://issues.apache.org/jira/browse/TS-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2308: -- Assignee: Bryan Call includedir in config.layout is not used --- Key: TS-2308 URL: https://issues.apache.org/jira/browse/TS-2308 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Craig Forbes Assignee: Bryan Call Fix For: 5.0.0 The includedir is hard coded as $(prefix)/include/ts in: mgmt/api/include/Makefile.am proxy/api/ts/Makefile.am so the value set in config.layout is ignored. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2332) Add Consistent Hash class to libts
[ https://issues.apache.org/jira/browse/TS-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002066#comment-14002066 ] Bryan Call commented on TS-2332: [~psudaemon] Please make change. Add Consistent Hash class to libts -- Key: TS-2332 URL: https://issues.apache.org/jira/browse/TS-2332 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.0.0 We may have a consistent hash implementation in the cluster code, but we don't have a general one available to libts. We need one to implement a consistent hash option for parent selection. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2344: -- Assignee: Bryan Call (was: Leif Hedstrom) 404 error was logged while url redirect request was processed corrctly -- Key: TS-2344 URL: https://issues.apache.org/jira/browse/TS-2344 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Eddie Assignee: Bryan Call Labels: Review Fix For: 5.0.0 Attachments: no_redirect_after_map.patch I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly and I could see the expected response in log as below: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed in the error log too, which generates a lot of error logs (log rotation configured) and filling up disk space pretty fast. 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly I could see the expected response in log as well: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed too: 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG proxy.config.log.extended2_log_enabled INT 0 CONFIG proxy.config.log.extended2_log_is_ascii INT 1 CONFIG proxy.config.log.extended2_log_name STRING extended2 CONFIG proxy.config.log.extended2_log_header STRING NULL CONFIG proxy.config.log.separate_icp_logs INT 0 CONFIG proxy.config.log.separate_host_logs INT 0 Is this a bug or is this a misconfiguration? Does anyone have any idea?) and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG proxy.config.log.extended2_log_enabled INT 0 CONFIG proxy.config.log.extended2_log_is_ascii INT 1 CONFIG
[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002072#comment-14002072 ] Bryan Call commented on TS-2362: [~amc] Per our discussion at LinkedIn this will be in the 5.1.0 release. Backwards cache compatibility for 4.X (read 3.2) Key: TS-2362 URL: https://issues.apache.org/jira/browse/TS-2362 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: Review Fix For: 5.1.0 Attachments: ts-2362.diff Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2362: --- Fix Version/s: (was: 5.0.0) 5.1.0 Backwards cache compatibility for 4.X (read 3.2) Key: TS-2362 URL: https://issues.apache.org/jira/browse/TS-2362 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: Review Fix For: 5.1.0 Attachments: ts-2362.diff Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002078#comment-14002078 ] Bryan Call commented on TS-2367: [~ffcai] Is there any updates on this? Add OCSP (Online Certificate Status Protocol) Stapling Support --- Key: TS-2367 URL: https://issues.apache.org/jira/browse/TS-2367 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Bryan Call Assignee: Bryan Call Labels: review Fix For: 5.0.0 Attachments: TS-2367.diff RFC: http://tools.ietf.org/html/rfc6066 Overview: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling http://en.wikipedia.org/wiki/OCSP_stapling There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2812) header_normalize to convert lower case spdy hdrs to camel case for backward compatibility
[ https://issues.apache.org/jira/browse/TS-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002092#comment-14002092 ] Sudheer Vinukonda commented on TS-2812: --- Umm..I do agree that the plugin is a workaround/cover, but, I am wondering if we should call the root cause (of sending lowercase SPDY headers to a HTTP/1 origin) a bug. I agree that, from a HTTP/1 origin's perspective, this would appear to be a behavior change, but, it looks like, even HTTP/1 seems to allow sending headers in any case (based on the above extract that requires the HTTP/1.x receiver to perform a case-insensitive comparison). header_normalize to convert lower case spdy hdrs to camel case for backward compatibility - Key: TS-2812 URL: https://issues.apache.org/jira/browse/TS-2812 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2812.diff During our SPDY testing, we observed that certain legacy systems are not able to handle lower case hdrs mandated by SPDY (and even http 1.0). This simple plugin converts the lowercase header names into camel case and could be used as an interim solution until the legacy systems are upgraded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2402) SSL v3 is disabled
[
https://issues.apache.org/jira/browse/TS-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2402:
--
Assignee: Bryan Call
SSL v3 is disabled
--
Key: TS-2402
URL: https://issues.apache.org/jira/browse/TS-2402
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Affects Versions: 4.2.0
Reporter: Neddy
Assignee: Bryan Call
Fix For: 5.0.0
Host OS: Debian x86_64
ATS 4.2.0
Usage: Reverse server SSL terminal
CONFIG proxy.config.ssl.SSLv2 INT 0
CONFIG proxy.config.ssl.SSLv3 INT 1
CONFIG proxy.config.ssl.TLSv1 INT 1
Error log:
[Nov 27 16:35:32.759] Server {0x2b1b5d18d700} ERROR:
SSL::3:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337
[Nov 27 16:35:32.759] Server {0x2b1b5d18d700} ERROR:
[SSL_NetVConnection::ssl_read_from_net]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2403) Segfault when HostDB full
[
https://issues.apache.org/jira/browse/TS-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2403:
---
Fix Version/s: (was: 5.0.0)
5.1.0
Segfault when HostDB full
-
Key: TS-2403
URL: https://issues.apache.org/jira/browse/TS-2403
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 4.0.1
Reporter: David Carlin
Labels: Crash
Fix For: 5.1.0
diags.log leading up to crash:
{noformat}
[Nov 25 10:50:23.346] Server {0x2b06c4302700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.379] Server {0x2b06c4100700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.449] Server {0x2b06c4a09700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.462] Server {0x2b06c4403700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.494] Server {0x2b06bed1f540} WARNING: out of room in hostdb
for reverse DNS data
[Nov 25 10:54:46.919] {0x2baa2d65b540} STATUS: opened
/home/y/logs/trafficserver/diags.log
[Nov 25 10:54:46.927] {0x2baa2d65b540} NOTE: updated diags config
[Nov 25 10:54:46.961] Server {0x2baa2d65b540} NOTE: cache clustering disabled
[Nov 25 10:54:46.995] Server {0x2baa2d65b540} NOTE: ip_allow.config updated,
reloading
[Nov 25 10:54:47.059] Server {0x2baa2d65b540} NOTE: cache clustering disabled
[Nov 25 10:54:47.072] Server {0x2baa2d65b540} NOTE: logging initialized[15],
logging_mode = 3
[Nov 25 10:54:47.103] Server {0x2baa2d65b540} NOTE: loading plugin
'/home/y/libexec64/trafficserver/quick_filter.so'
[Nov 25 10:54:47.326] Server {0x2baa2d65b540} NOTE: loading plugin
'/home/y/libexec64/trafficserver/header_filter.so'
[Nov 25 10:54:49.395] Server {0x2baa2d65b540} NOTE: traffic server running
{noformat}
From traffic.out:
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3d07c0f500)[0x2b06be27a500]
/home/y/bin/traffic_server(_Z14ats_ip_addr_eqPK8sockaddrS1_+0x3)[0x5e0323]
/home/y/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x2389)[0x5df3b9]
/home/y/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f9cd4]
/home/y/bin/traffic_server[0x5fbd17]
/home/y/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x8d0)[0x5fd5c0]
/home/y/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x12)[0x5fe642]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a321f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a3c03]
/home/y/bin/traffic_server(main+0xb14)[0x4c5314]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3d0781ecdd]
/home/y/bin/traffic_server[0x485a19]
{noformat}
Backtrace:
{noformat}
#0 ats_ip_addr_cmp (lhs=0x7fffdf15e778, rhs=0x8) at
../../lib/ts/ink_inet.h:669
#1 ats_ip_addr_eq (lhs=0x7fffdf15e778, rhs=0x8) at
../../lib/ts/ink_inet.h:721
#2 0x005df3b9 in restore_info (this=value optimized out,
event=value optimized out, e=value optimized out) at HostDB.cc:1375
#3 HostDBContinuation::dnsEvent (this=value optimized out, event=value
optimized out, e=value optimized out) at HostDB.cc:1604
#4 0x005f9cd4 in handleEvent (this=0x2b06f40a2120) at
../../iocore/eventsystem/I_Continuation.h:146
#5 DNSEntry::postEvent (this=0x2b06f40a2120) at DNS.cc:1278
#6 0x005fbd17 in dns_result (h=0x1778380, e=0x2b06f40a2120,
ent=0x1913820, retry=value optimized out) at DNS.cc:1230
#7 0x005fd5c0 in dns_process (this=0x1778380) at DNS.cc:1599
#8 DNSHandler::recv_dns (this=0x1778380) at DNS.cc:790
#9 0x005fe642 in DNSHandler::mainEvent (this=0x1778380, event=value
optimized out, e=value optimized out) at DNS.cc:802
#10 0x006a321f in handleEvent (this=0x2b06bf2d0010, e=0x2b06d8092740,
calling_code=5) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b06bf2d0010, e=0x2b06d8092740,
calling_code=5) at UnixEThread.cc:141
#12 0x006a3c03 in EThread::execute (this=0x2b06bf2d0010) at
UnixEThread.cc:265
#13 0x004c5314 in main (argv=value optimized out) at Main.cc:1690
{noformat}
HostDB settings:
CONFIG proxy.config.hostdb.size INT 20
CONFIG proxy.config.hostdb.storage_size INT 50331648
CONFIG proxy.config.hostdb.ttl_mode INT 0
CONFIG proxy.config.hostdb.timeout INT 1440
CONFIG proxy.config.hostdb.strict_round_robin INT 0
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2383) Strange errors / warnings from make install related to man pages
[
https://issues.apache.org/jira/browse/TS-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2383:
---
Fix Version/s: (was: 5.0.0)
sometime
Strange errors / warnings from make install related to man pages
Key: TS-2383
URL: https://issues.apache.org/jira/browse/TS-2383
Project: Traffic Server
Issue Type: Bug
Components: Build, Documentation
Reporter: Leif Hedstrom
Fix For: sometime
I get
{code}
traffic_cop.8 { } None:None: WARNING: No definition found for configuration
variable 'proxy.config.cop.linux_min_memfree_kb'
None:None: WARNING: file reference target not found: /tmp/traffic_cop.trace
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2407) we should add API TSUrlStringGetBuf in ts.h
[
https://issues.apache.org/jira/browse/TS-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2407:
-
Assignee: Leif Hedstrom (was: James Peach)
we should add API TSUrlStringGetBuf in ts.h
---
Key: TS-2407
URL: https://issues.apache.org/jira/browse/TS-2407
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Yu Qing
Assignee: Leif Hedstrom
Labels: api-addition, review
Fix For: 5.1.0
Attachments: 0001-TS-2407-add-API-TSUrlStringGetBuf.patch
the existing API TSUrlStringGet call ats_malloc to malloc buffer for the url
string. the caller should call ats_free to free the buffer. the API prototype
is:
tsapi char* TSUrlStringGet(TSMBuffer bufp, TSMLoc offset, int* length);
call this API is expensive because dynamic memory alloc and free.
we wish the buffer can be passed in. the new API prototype is:
tsapi char* TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc offset, char *buff, int
buf_size, int* length);
the implements as:
char *
TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc obj, char *buff, int buf_size, int*
length)
{
sdk_assert(sdk_sanity_check_mbuffer(bufp) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_url_handle(obj) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)buff) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)length) == TS_SUCCESS);
URLImpl *url_impl = (URLImpl *) obj;
return url_string_get_buf(url_impl, buff, buf_size, length);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2407) we should add API TSUrlStringGetBuf in ts.h
[
https://issues.apache.org/jira/browse/TS-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2407:
---
Fix Version/s: (was: 5.0.0)
5.1.0
we should add API TSUrlStringGetBuf in ts.h
---
Key: TS-2407
URL: https://issues.apache.org/jira/browse/TS-2407
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Yu Qing
Assignee: James Peach
Labels: api-addition, review
Fix For: 5.1.0
Attachments: 0001-TS-2407-add-API-TSUrlStringGetBuf.patch
the existing API TSUrlStringGet call ats_malloc to malloc buffer for the url
string. the caller should call ats_free to free the buffer. the API prototype
is:
tsapi char* TSUrlStringGet(TSMBuffer bufp, TSMLoc offset, int* length);
call this API is expensive because dynamic memory alloc and free.
we wish the buffer can be passed in. the new API prototype is:
tsapi char* TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc offset, char *buff, int
buf_size, int* length);
the implements as:
char *
TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc obj, char *buff, int buf_size, int*
length)
{
sdk_assert(sdk_sanity_check_mbuffer(bufp) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_url_handle(obj) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)buff) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)length) == TS_SUCCESS);
URLImpl *url_impl = (URLImpl *) obj;
return url_string_get_buf(url_impl, buff, buf_size, length);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2411) TS Http byte get functions does not return the true number, for server response body byte get
[ https://issues.apache.org/jira/browse/TS-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002112#comment-14002112 ] Bryan Call commented on TS-2411: [~briang] Any updates? TS Http byte get functions does not return the true number, for server response body byte get - Key: TS-2411 URL: https://issues.apache.org/jira/browse/TS-2411 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Roee Gil Assignee: Brian Geffon Labels: api-change Fix For: 5.0.0 When using the example of null-transform, adding TS_EVENT_HTTP_TXN_CLOSE to hooks, and counting byte number, I get: // server - proxy TSHttpTxnServerRespHdrBytesGet(txnDB); TSHttpTxnServerRespBodyBytesGet(txnDB); // proxy - client TSHttpTxnClientRespHdrBytesGet(txnDB); TSHttpTxnClientRespBodyBytesGet(txnDB); 1. server side response body = 0 2. client side response body = (payload size) when inspecting this issue, it seems that VConnection is downloading the content but, this does not count in server response byte get -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2417) forward secrecy for non-EC key types
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2417: --- Fix Version/s: (was: 5.0.0) 5.1.0 forward secrecy for non-EC key types Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, Security, SSL Reporter: Bryan Call Assignee: James Peach Fix For: 5.1.0 mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2428) Move new_Deleter to run on ET_TASK
[ https://issues.apache.org/jira/browse/TS-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2428: --- Assignee: Leif Hedstrom Move new_Deleter to run on ET_TASK -- Key: TS-2428 URL: https://issues.apache.org/jira/browse/TS-2428 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 As of some recent changes, it would make sense to also schedule new_Deleter tasks on the ET_TASK thread pool. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2442) Validation strings in RecordsConfig.cc are ignored (or not correctly handled)
[ https://issues.apache.org/jira/browse/TS-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2442: --- Fix Version/s: (was: 5.0.0) 5.1.0 Validation strings in RecordsConfig.cc are ignored (or not correctly handled) - Key: TS-2442 URL: https://issues.apache.org/jira/browse/TS-2442 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Fix For: 5.1.0 We have all these nice validation strings / regexes / ranges in RecordsConfig.cc, but it seems we take little or no action on failures on them. We should fix that. Also see TS-1992. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2411) TS Http byte get functions does not return the true number, for server response body byte get
[ https://issues.apache.org/jira/browse/TS-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002127#comment-14002127 ] Brian Geffon commented on TS-2411: -- Nope, I started looking into this but dropped it, I can try to pick it up in two weeks or so. TS Http byte get functions does not return the true number, for server response body byte get - Key: TS-2411 URL: https://issues.apache.org/jira/browse/TS-2411 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Roee Gil Assignee: Brian Geffon Labels: api-change Fix For: 5.0.0 When using the example of null-transform, adding TS_EVENT_HTTP_TXN_CLOSE to hooks, and counting byte number, I get: // server - proxy TSHttpTxnServerRespHdrBytesGet(txnDB); TSHttpTxnServerRespBodyBytesGet(txnDB); // proxy - client TSHttpTxnClientRespHdrBytesGet(txnDB); TSHttpTxnClientRespBodyBytesGet(txnDB); 1. server side response body = 0 2. client side response body = (payload size) when inspecting this issue, it seems that VConnection is downloading the content but, this does not count in server response byte get -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2447) Cache fails to load / initialize, seems stuck on directory entry cleanup
[
https://issues.apache.org/jira/browse/TS-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2447:
---
Fix Version/s: (was: 5.0.0)
5.1.0
Cache fails to load / initialize, seems stuck on directory entry cleanup
Key: TS-2447
URL: https://issues.apache.org/jira/browse/TS-2447
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 5.1.0
We had an issue where a number of machines would not startup properly. They
get stuck on reading / initializing the cache. It initializes the caches with
{code}
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 0:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 1:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 2:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 3:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 4:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 5:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 6:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 65536
[Dec 20 16:45:40.198] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.201] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.204] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.208] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.213] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.219] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.224] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
{code}
After this, it enters a stage where it’s doing a *lot* of dir_clean events:
{code}
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f028 tag 0 boffset 0 b 0x7f3edcd6f028 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f050 tag 0 boffset 0 b 0x7f3edcd6f050 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f078 tag 0 boffset 0 b 0x7f3edcd6f078 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0a0 tag 0 boffset 0 b 0x7f3edcd6f0a0 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0c8 tag 0 boffset 0 b
[jira] [Updated] (TS-2443) cache.config isn't suitable for forward caching
[ https://issues.apache.org/jira/browse/TS-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2443: --- Fix Version/s: (was: 5.1.0) 5.0.0 cache.config isn't suitable for forward caching --- Key: TS-2443 URL: https://issues.apache.org/jira/browse/TS-2443 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: zhiyuanfu Assignee: James Peach Fix For: 5.0.0 Use ats for forward caching. Many objects' header have not cache control information. So I use ttl-in-cache to forced to control cache,but ttl-in-cache will cause many problems when using forward cacheing. Like range object will be cached as a intact object for next time request. Our cache control plugin: https://github.com/acache/stateam_trafficserver/tree/master -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2449) I find INKUDPRecvFrom can not work .
[ https://issues.apache.org/jira/browse/TS-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2449: --- Assignee: (was: weijin) I find INKUDPRecvFrom can not work . - Key: TS-2449 URL: https://issues.apache.org/jira/browse/TS-2449 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.1.2 Reporter: xinyuziran Fix For: 5.1.0 Attachments: iocore.patch, main.patch, udp_patch.txt I find INKUDPBind can bind udp port, but INKUDPRecvFrom can't recive udp data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2462) FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation which is deleted`
[
https://issues.apache.org/jira/browse/TS-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-2462.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.0.0)
Please reopen with more details if this is still an issue.
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
Key: TS-2462
URL: https://issues.apache.org/jira/browse/TS-2462
Project: Traffic Server
Issue Type: Bug
Components: HTTP, TS API
Reporter: bettydramit
Labels: crash
4.0.1 -4.1.2
{code}
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.4(+0x141e8)[0x2b716e8ac1e8]
/usr/lib64/trafficserver/libtsutil.so.4(+0x128df)[0x2b716e8aa8df]
/usr/bin/traffic_server[0x4af6b4]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4d08b5]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4d120a]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x2c3)[0x4d2123]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a37ff]
/usr/bin/traffic_server(EThread::execute()+0x6e3)[0x6a4423]
/usr/bin/traffic_server[0x6a269a]
/lib64/libpthread.so.0(+0x7851)[0x2b7170708851]
/lib64/libc.so.6(clone+0x6d)[0x2b71713ac90d]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2470) PCT type metrics seems out of whack
[
https://issues.apache.org/jira/browse/TS-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002136#comment-14002136
]
Bryan Call commented on TS-2470:
We should just remove all the percentage stats.
PCT type metrics seems out of whack
---
Key: TS-2470
URL: https://issues.apache.org/jira/browse/TS-2470
Project: Traffic Server
Issue Type: Bug
Components: Metrics
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
From my latest master build:
{code}
proxy.node.bandwidth_hit_ratio_int_pct=429227680
proxy.node.hostdb.hit_ratio_int_pct=1116599040
proxy.node.cache_hit_ratio_int_pct=419143744
proxy.node.bandwidth_hit_ratio_avg_10s_int_pct=362055712
proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct=50927432
proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct=50927432
proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct=1018548608
proxy.node.cache.percent_free_int_pct=1077459456
{code}
Neither of these seem particularly reasonable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2470) PCT type metrics seems out of whack
[
https://issues.apache.org/jira/browse/TS-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2470:
---
Fix Version/s: (was: 5.0.0)
5.1.0
PCT type metrics seems out of whack
---
Key: TS-2470
URL: https://issues.apache.org/jira/browse/TS-2470
Project: Traffic Server
Issue Type: Bug
Components: Metrics
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.1.0
From my latest master build:
{code}
proxy.node.bandwidth_hit_ratio_int_pct=429227680
proxy.node.hostdb.hit_ratio_int_pct=1116599040
proxy.node.cache_hit_ratio_int_pct=419143744
proxy.node.bandwidth_hit_ratio_avg_10s_int_pct=362055712
proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct=50927432
proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct=50927432
proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct=1018548608
proxy.node.cache.percent_free_int_pct=1077459456
{code}
Neither of these seem particularly reasonable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002151#comment-14002151 ] Bryan Call commented on TS-2480: [~jamespeach] Can you please respond to Wei's last comment? Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Labels: review Fix For: 5.0.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.2#6252)
