[jira] [Commented] (TS-3415) H2 sending FIN stream too early
[
https://issues.apache.org/jira/browse/TS-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345227#comment-14345227
]
Sudheer Vinukonda commented on TS-3415:
---
[~rokubo]: Your patch resolves this bug, but, I wonder, if it would make sense
to have some sort of (independent) protection to not send out any data frames
after FIN.
H2 sending FIN stream too early
---
Key: TS-3415
URL: https://issues.apache.org/jira/browse/TS-3415
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Sudheer Vinukonda
Attachments: ts-3415-02.diff, ts-3415-3414.diff, ts-3415.diff
With H2 running on the docs/jenkins server, some of us have noticed empty
pages on chrome/FF when hitting those servers. Looking at the H2 traces, it
seems that ATS is sending FIN streams (both SPDY_SESSION_RECV_HEADERS and
SPDY_SESSION_RECV_DATA with fin flag set to true) before sending the data
frames. This makes the browser display blank pages.
Example:
{code}
t=31890437 [st=140]SPDY_SESSION_RECV_DATA
-- fin = true
-- size = 0
-- stream_id = 1
t=31890437 [st=140]SPDY_SESSION_RECV_DATA
-- fin = false
-- size = 2591
-- stream_id = 1
{code}
Detailed traces below:
{code}
1112054: SPDY_SESSION
ci.trafficserver.apache.org:443 (DIRECT)
Start Time: 2015-02-26 13:30:14.060
t=31890297 [st= 0] +SPDY_SESSION [dt=?]
-- host = ci.trafficserver.apache.org:443
-- proxy = DIRECT
t=31890297 [st= 0]SPDY_SESSION_INITIALIZED
-- protocol = h2-14
-- source_dependency = 1112049 (SOCKET)
t=31890297 [st= 0]SPDY_SESSION_SEND_SETTINGS
-- settings = [[id:3 flags:0 value:1000],[id:4
flags:0 value:10485760]]
t=31890297 [st= 0]SPDY_STREAM_UPDATE_RECV_WINDOW
-- delta = 10420224
-- window_size = 10485760
t=31890297 [st= 0]SPDY_SESSION_SENT_WINDOW_UPDATE_FRAME
-- delta = 10420224
-- stream_id = 0
t=31890297 [st= 0]SPDY_SESSION_SYN_STREAM
-- fin = true
-- :authority: ci.trafficserver.apache.org
:method: GET
:path: /job/tsqa-master/180/consoleFull
:scheme: https
accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-encoding: gzip, deflate, sdch
accept-language: en-US,en;q=0.8
cache-control: max-age=0
cookie: [71 bytes were stripped]
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115
Safari/537.36
-- spdy_priority = 0
-- stream_id = 1
-- unidirectional = false
t=31890335 [st= 38]SPDY_SESSION_RECV_SETTINGS
-- clear_persisted = false
-- host = ci.trafficserver.apache.org:443
t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
-- flags = 0
-- id = 1
-- value = 4096
t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
-- flags = 0
-- id = 2
-- value = 0
t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
-- flags = 0
-- id = 3
-- value = 100
t=31890436 [st=139]SPDY_SESSION_RECV_HEADERS
-- fin = true
-- :status: 200
age: 1
cache-control: no-cache,no-store,must-revalidate
content-encoding: gzip
content-type: text/html;charset=UTF-8
date: Thu, 26 Feb 2015 21:30:14 GMT
expires: Thu, 01 Jan 1970 00:00:00 GMT
server: ATS/5.3.0
set-cookie: [67 bytes were stripped]
strict-transport-security: max-age=86400
via: http/1.1 ATS (ApacheTrafficServer/5.3.0
[cMsSf ])
x-frame-options: sameorigin
x-hudson: 1.395
x-hudson-cli-port: 40666
x-hudson-theme: default
[jira] [Commented] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345322#comment-14345322 ] ASF subversion and git services commented on TS-3414: - Commit efae3a4f914a7dda7b3f586a0c09c93435b90efb in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=efae3a4 ] [TS-3414]: Add new TS API TSHttpTxnOutgoingAddrGet New API for Outgoing Address - Key: TS-3414 URL: https://issues.apache.org/jira/browse/TS-3414 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 5.3.0 Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Fix For: 5.3.0 There's currently no TS API to retrieve the source address used by the proxy in the outbound connections. I would like to add a new TS API that can provide this info - In addition to making it consistent with the API for inbound addresses (where we have TS API for both remote and local addresses), there may be other use cases that need this info (e.g. applying rate limiting on the inbound side based on the ephemeral ports). tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3414: -- Affects Version/s: 5.3.0 Fix Version/s: 5.3.0 Assignee: Sudheer Vinukonda New API for Outgoing Address - Key: TS-3414 URL: https://issues.apache.org/jira/browse/TS-3414 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 5.3.0 Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Fix For: 5.3.0 There's currently no TS API to retrieve the source address used by the proxy in the outbound connections. I would like to add a new TS API that can provide this info - In addition to making it consistent with the API for inbound addresses (where we have TS API for both remote and local addresses), there may be other use cases that need this info (e.g. applying rate limiting on the inbound side based on the ephemeral ports). tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345339#comment-14345339 ] ASF subversion and git services commented on TS-3414: - Commit cd60e20bd4b554930a4d6eef77762154f5b1aed8 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cd60e20 ] [TS-3414]: Update docs for TSHttpTxnOutgoingAddrGet and TSHttpTxnIncomingAddrGet New API for Outgoing Address - Key: TS-3414 URL: https://issues.apache.org/jira/browse/TS-3414 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 5.3.0 Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Fix For: 5.3.0 There's currently no TS API to retrieve the source address used by the proxy in the outbound connections. I would like to add a new TS API that can provide this info - In addition to making it consistent with the API for inbound addresses (where we have TS API for both remote and local addresses), there may be other use cases that need this info (e.g. applying rate limiting on the inbound side based on the ephemeral ports). tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-3414. --- Resolution: Fixed New API for Outgoing Address - Key: TS-3414 URL: https://issues.apache.org/jira/browse/TS-3414 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 5.3.0 Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Fix For: 5.3.0 There's currently no TS API to retrieve the source address used by the proxy in the outbound connections. I would like to add a new TS API that can provide this info - In addition to making it consistent with the API for inbound addresses (where we have TS API for both remote and local addresses), there may be other use cases that need this info (e.g. applying rate limiting on the inbound side based on the ephemeral ports). tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345606#comment-14345606 ] Kit Chan commented on TS-3414: -- I saw you updated the lua plugin as well to add this feature. Thanks. Can you please update the lua plugin doc as well? https://github.com/apache/trafficserver/blob/master/doc/reference/plugins/ts_lua.en.rst Thanks. New API for Outgoing Address - Key: TS-3414 URL: https://issues.apache.org/jira/browse/TS-3414 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 5.3.0 Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Fix For: 5.3.0 There's currently no TS API to retrieve the source address used by the proxy in the outbound connections. I would like to add a new TS API that can provide this info - In addition to making it consistent with the API for inbound addresses (where we have TS API for both remote and local addresses), there may be other use cases that need this info (e.g. applying rate limiting on the inbound side based on the ephemeral ports). tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3421) Add a -t range feature for authproxy plugin
[ https://issues.apache.org/jira/browse/TS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345505#comment-14345505 ] ASF subversion and git services commented on TS-3421: - Commit 9f7cdf8d13dcf90842a74af1db24b53ca1d2cfc1 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9f7cdf8 ] TS-3421 Updated docs Add a -t range feature for authproxy plugin --- Key: TS-3421 URL: https://issues.apache.org/jira/browse/TS-3421 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.0 Similar to the -t head option, this would send a request asking for no body. The difference is that we use the GET request, which can allow more proxies to actually fetch and serve the authproxy request from cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3311) Possible lookups on NULL hostnames in HostDB
[ https://issues.apache.org/jira/browse/TS-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345654#comment-14345654 ] Leif Hedstrom commented on TS-3311: --- The patch looks fine. I haven't tried to reproduce the bug with it, but my observations on this triggering is as follow: 1) The recursive resolve needs to resolve localhost. 2) parent.config has to exist. I'm not 100% certain, but I don't think it has to be enabled (we parse parent.config regardless if it's enabled or not). 3) It'll only trigger once the entry for localhost is in the HostDB cache, and the TTL expires. I.e. on revalidation of the entry. 4) It seems to primarily happen on the traffic_cop health checks (i.e. proxying http://127.0.0.1:8083/synthetic.txt). Possible lookups on NULL hostnames in HostDB Key: TS-3311 URL: https://issues.apache.org/jira/browse/TS-3311 Project: Traffic Server Issue Type: Bug Components: HostDB Reporter: Steve Malenfant Assignee: Alan M. Carroll Fix For: 5.3.0 Getting multiple segfaults per day on 4.2.1. [4324544.324222] [ET_NET 23][10504]: segfault at 0 ip 2acd66546168 sp 2acd71f190b8 error 4 in libtsutil.so.4.2.1[2acd66521000+34000] [4410696.820857] [ET_NET 19][22738]: segfault at 0 ip 2af09f339168 sp 2af0aa9230b8 error 4 in libtsutil.so.4.2.1[2af09f314000+34000] [4497039.474253] [ET_NET 12][34872]: segfault at 0 ip 2ad17e6a1168 sp 2ad1896100b8 error 4 in libtsutil.so.4.2.1[2ad17e67c000+34000] [4583372.073916] [ET_NET 3][46994]: segfault at 0 ip 2aced4227168 sp 2aceda7d80b8 error 4 in libtsutil.so.4.2.1[2aced4202000+34000] [4756046.944373] [ET_NET 22][10799]: segfault at 0 ip 2b1771f76168 sp 2b177d9130b8 error 4 in libtsutil.so.4.2.1[2b1771f51000+34000] Stack Trace : (gdb) bt #0 ink_inet_addr (s=value optimized out) at ink_inet.cc:107 #1 0x005e0df5 in is_dotted_form_hostname (mutex=0x1d32cb0, md5=..., ignore_timeout=false) at P_HostDBProcessor.h:545 #2 probe (mutex=0x1d32cb0, md5=..., ignore_timeout=false) at HostDB.cc:668 #3 0x005e2b34 in HostDBProcessor::getby (this=value optimized out, cont=0x2b514cc749d0, hostname=0x0, len=value optimized out, ip=0x2b50e8f092b0, aforce_dns=false, host_res_style=HOST_RES_NONE, dns_lookup_timeout=0) at HostDB.cc:772 #4 0x00517f2c in getbyaddr_re (this=0x2b514cc749d0) at ../../iocore/hostdb/I_HostDBProcessor.h:417 #5 HttpSM::do_hostdb_reverse_lookup (this=0x2b514cc749d0) at HttpSM.cc:3968 #6 0x0052f028 in HttpSM::set_next_state (this=0x2b514cc749d0) at HttpSM.cc:6932 #7 0x00518242 in HttpSM::do_hostdb_lookup (this=0x2b514cc749d0) at HttpSM.cc:3950 #8 0x0052f44a in HttpSM::set_next_state (this=0x2b514cc749d0) at HttpSM.cc:6925 #9 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at HttpSM.cc:1559 #10 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at HttpSM.cc:6825 #11 0x0052ea8a in HttpSM::set_next_state (this=0x2b514cc749d0) at HttpSM.cc:7224 #12 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at HttpSM.cc:1559 #13 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at HttpSM.cc:6825 #14 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at HttpSM.cc:1559 #15 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at HttpSM.cc:6825 #16 0x0052fef6 in HttpSM::state_read_client_request_header (this=0x2b514cc749d0, event=100, data=value optimized out) at HttpSM.cc:821 #17 0x0052a5b8 in HttpSM::main_handler (this=0x2b514cc749d0, event=100, data=0x2b514802ca08) at HttpSM.cc:2539 #18 0x0068793b in handleEvent (event=value optimized out, vc=0x2b514802c900) at ../../iocore/eventsystem/I_Continuation.h:146 #19 read_signal_and_update (event=value optimized out, vc=0x2b514802c900) at UnixNetVConnection.cc:138 #20 0x00689ec4 in read_from_net (nh=0x2b50e2e17c10, vc=0x2b514802c900, thread=value optimized out) at UnixNetVConnection.cc:320 #21 0x0067fb12 in NetHandler::mainNetEvent (this=0x2b50e2e17c10, event=value optimized out, e=value optimized out) at UnixNet.cc:384 #22 0x006ac8cf in handleEvent (this=0x2b50e2e14010, e=0x1a9ef30, calling_code=5) at I_Continuation.h:146 #23 EThread::process_event (this=0x2b50e2e14010, e=0x1a9ef30, calling_code=5) at UnixEThread.cc:145 #24 0x006ad273 in EThread::execute (this=0x2b50e2e14010) at UnixEThread.cc:269 #25 0x006abc2a in spawn_thread_internal (a=0x198f820) at Thread.cc:88 #26 0x2b50e026b9d1 in start_thread () from /lib64/libpthread.so.0 #27 0x00381b2e8b6d in clone () from /lib64/libc.so.6 -- This message was sent by
[jira] [Commented] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345768#comment-14345768 ] Leif Hedstrom commented on TS-3197: --- [~amc] Is it reasonable to leave this as an Improvement Jira? Is anyone going to work on this? dest_ip in cache.config should be expand to network style - Key: TS-3197 URL: https://issues.apache.org/jira/browse/TS-3197 Project: Traffic Server Issue Type: Improvement Components: Cache, Configuration, Performance Reporter: Luca Rea Priority: Minor Fix For: sometime Hi, I'm tring to exclude a /22 netblock from the cache system but the syntax dest_ip doesn't work, detalis below: dest_ip=x.y.84.0-x.y.87.255 action=never-cache I've tried to stop,clear-cache,start several times but every time images have been put into the cache and log shows NONE FIN FIN TCP_MEM_HIT or NONE FIN FIN TCP_IMS_HIT. Other Info: proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-3197: -- Summary: dest_ip in cache.config should be expand to network style (was: dest_ip in cache.config doesn't work) dest_ip in cache.config should be expand to network style - Key: TS-3197 URL: https://issues.apache.org/jira/browse/TS-3197 Project: Traffic Server Issue Type: Bug Components: Cache, Configuration, Performance Reporter: Luca Rea Fix For: sometime Hi, I'm tring to exclude a /22 netblock from the cache system but the syntax dest_ip doesn't work, detalis below: dest_ip=x.y.84.0-x.y.87.255 action=never-cache I've tried to stop,clear-cache,start several times but every time images have been put into the cache and log shows NONE FIN FIN TCP_MEM_HIT or NONE FIN FIN TCP_IMS_HIT. Other Info: proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-3197: -- Priority: Minor (was: Major) dest_ip in cache.config should be expand to network style - Key: TS-3197 URL: https://issues.apache.org/jira/browse/TS-3197 Project: Traffic Server Issue Type: Improvement Components: Cache, Configuration, Performance Reporter: Luca Rea Priority: Minor Fix For: sometime Hi, I'm tring to exclude a /22 netblock from the cache system but the syntax dest_ip doesn't work, detalis below: dest_ip=x.y.84.0-x.y.87.255 action=never-cache I've tried to stop,clear-cache,start several times but every time images have been put into the cache and log shows NONE FIN FIN TCP_MEM_HIT or NONE FIN FIN TCP_IMS_HIT. Other Info: proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-3197: -- Issue Type: Improvement (was: Bug) dest_ip in cache.config should be expand to network style - Key: TS-3197 URL: https://issues.apache.org/jira/browse/TS-3197 Project: Traffic Server Issue Type: Improvement Components: Cache, Configuration, Performance Reporter: Luca Rea Fix For: sometime Hi, I'm tring to exclude a /22 netblock from the cache system but the syntax dest_ip doesn't work, detalis below: dest_ip=x.y.84.0-x.y.87.255 action=never-cache I've tried to stop,clear-cache,start several times but every time images have been put into the cache and log shows NONE FIN FIN TCP_MEM_HIT or NONE FIN FIN TCP_IMS_HIT. Other Info: proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[
https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344988#comment-14344988
]
Feifei Cai commented on TS-2497:
For *redirect GET* use case, the test is as follows:
{noformat}
$ curl http://httpbin.org/redirect-to?url=http://httpbin.org/get -L -v
{noformat}
However, the *redirect POST* request is not support:
{noformat}
$ curl http://httpbin.org/redirect-to?url=http://httpbin.org/post -d xxx -L -v
{noformat}
References:
# http://httpbin.org/
# https://github.com/Runscope/httpbin/issues/156
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, client.js, origin-server.js, 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.3.4#6332)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344875#comment-14344875 ] Feifei Cai commented on TS-2497: Not quite clear about the POST/PUT redirection use case. For GET methods, I have simple test case; however, I have not set up a test case for POST redirection yet. BTW, I tried reverting the patch , i.e. deallocate memory in both no origin server response and receive origin server response cases, it runs stable for ~3 days in our production server. 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, client.js, origin-server.js, 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.3.4#6332)
[jira] [Commented] (TS-3212) 200 code is returned as 304
[
https://issues.apache.org/jira/browse/TS-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344764#comment-14344764
]
Luca Rea commented on TS-3212:
--
Hi Zhao,
the workaround I've applied has been to disable cache of dynamic urls:
CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
Like you already explained I suppose cache.config is not working as expected.
200 code is returned as 304
---
Key: TS-3212
URL: https://issues.apache.org/jira/browse/TS-3212
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Luca Rea
Fix For: sometime
The live streaming videos from akamaihd.net CDN cannot be watched because ATS
rewrite codes 200 into 304 and videos enter continuosly in buffering status:
{code}
GET
http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKRb=500,300,700,900,1200hdcore=3.1.0plugin=aasp-3.1.0.43.124
HTTP/1.1
Host: abclive.abcnews.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer:
http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
Connection: keep-alive
HTTP/1.1 200 OK
Server: ContactLab
Mime-Version: 1.0
Content-Type: video/abst
Content-Length: 122
Last-Modified: Tue, 25 Nov 2014 05:28:32 GMT
Expires: Tue, 25 Nov 2014 15:31:53 GMT
Cache-Control: max-age=0, no-cache
Pragma: no-cache
Date: Tue, 25 Nov 2014 15:31:53 GMT
access-control-allow-origin: *
Set-Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==; path=/z/abc_live1@136327/;
domain=abclive.abcnews.com
Age: 0
Connection: keep-alive
GET
http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKRb=500,300,700,900,1200hdcore=3.1.0plugin=aasp-3.1.0.43.124
HTTP/1.1
Host: abclive.abcnews.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer:
http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
Connection: keep-alive
If-Modified-Since: Tue, 25 Nov 2014 05:28:32 GMT
HTTP/1.1 304 Not Modified
Date: Tue, 25 Nov 2014 15:31:58 GMT
Expires: Tue, 25 Nov 2014 15:31:58 GMT
Cache-Control: max-age=0, no-cache
Connection: keep-alive
Server: ContactLab
{code}
using the url_regex to skip cache/IMS doesn't work, the workaround is the
following line in records.config:
CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3212) 200 code is returned as 304
[
https://issues.apache.org/jira/browse/TS-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344883#comment-14344883
]
Zhao Yongming commented on TS-3212:
---
yeah, let us start tracking on cache control issue then.
and what confusing me is that why IMS is there if your resonse including all
the 'no-cache' directives to inform the client that the content is not
cache-able. that is weird.
anyway, keep this issue open until we fix the cache-control and recheck it.
200 code is returned as 304
---
Key: TS-3212
URL: https://issues.apache.org/jira/browse/TS-3212
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Luca Rea
Fix For: sometime
The live streaming videos from akamaihd.net CDN cannot be watched because ATS
rewrite codes 200 into 304 and videos enter continuosly in buffering status:
{code}
GET
http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKRb=500,300,700,900,1200hdcore=3.1.0plugin=aasp-3.1.0.43.124
HTTP/1.1
Host: abclive.abcnews.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer:
http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
Connection: keep-alive
HTTP/1.1 200 OK
Server: ContactLab
Mime-Version: 1.0
Content-Type: video/abst
Content-Length: 122
Last-Modified: Tue, 25 Nov 2014 05:28:32 GMT
Expires: Tue, 25 Nov 2014 15:31:53 GMT
Cache-Control: max-age=0, no-cache
Pragma: no-cache
Date: Tue, 25 Nov 2014 15:31:53 GMT
access-control-allow-origin: *
Set-Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==; path=/z/abc_live1@136327/;
domain=abclive.abcnews.com
Age: 0
Connection: keep-alive
GET
http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKRb=500,300,700,900,1200hdcore=3.1.0plugin=aasp-3.1.0.43.124
HTTP/1.1
Host: abclive.abcnews.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer:
http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
Connection: keep-alive
If-Modified-Since: Tue, 25 Nov 2014 05:28:32 GMT
HTTP/1.1 304 Not Modified
Date: Tue, 25 Nov 2014 15:31:58 GMT
Expires: Tue, 25 Nov 2014 15:31:58 GMT
Cache-Control: max-age=0, no-cache
Connection: keep-alive
Server: ContactLab
{code}
using the url_regex to skip cache/IMS doesn't work, the workaround is the
following line in records.config:
CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
