[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)