[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}
>
>
>
>
>
>
>
>
> "/>
>
>
>
>
>
>
> {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-tabpanel&focusedCommentId=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:2
[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 %
[
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 %
> -
>
> 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:
> % % % %/% % % % %
> %/% % % % \"%<{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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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::hand
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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
> HttpTrans
[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-tabpanel&focusedCommentId=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= 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] [Closed] (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 closed TS-2218. -- Resolution: Won't Fix I agree we should just use TSConfigDirGet(). > 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-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 % and % 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] [Commented] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002025#comment-14002025 ] Bryan Call commented on TS-2253: The patch in the comment above looks to be working for both ATS 4.0.2 and ATS 5.0 (master) > 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]
> 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 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 status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent 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 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent 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 prox
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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=,
> event=, e=) at HostDB.cc:1375
> #3 HostDBContinuation::dnsEvent (this=, event= optimized out>, e=) 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=) 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= optimized out>, e=) 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=) 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-tabpanel&focusedCommentId=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] [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.0.0) 5.1.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.1.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] [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-tabpanel&focusedCommentId=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 {0
[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: --- Fix Version/s: (was: 5.0.0) 5.1.0 > 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 >Assignee: weijin > 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] [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)
