[jira] [Commented] (TS-2792) Large request header causes unexpected remap
[
https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994851#comment-13994851
]
Masakazu Kitajo commented on TS-2792:
-
You might be able to reproduce the issue with these setting and requests.
* records.conf
Everything is default value.
* remap.conf
{noformat}
regex_map http://foo.yahoo.co.jp/ http://localhost:8080/
{noformat}
Sample requests which breaks remap.
Sample1:
{noformat}
GET /foo/bar HTTP/1.1
User-Agent: u
Accept: */*
X:
Y:
yyy
Host: foo.yahoo.co.jp
{noformat}
Sample2:
{noformat}
GET /foo/bar HTTP/1.1
User-Agent:
uuu
Accept: */*
X:
Y:
[jira] [Closed] (TS-2716) Fix indentation for ts_lua plugin
[ https://issues.apache.org/jira/browse/TS-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan closed TS-2716. Resolution: Fixed Fix indentation for ts_lua plugin - Key: TS-2716 URL: https://issues.apache.org/jira/browse/TS-2716 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Assignee: Kit Chan Fix For: 5.0.0 We should run all the C code through our normal indent command, to get the code to align with our standards. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2636) Enhance ATS custom logging to support WIPE_FIELD_VALUE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2636: -- Assignee: Bryan Call (was: Yunkai Zhang) Enhance ATS custom logging to support WIPE_FIELD_VALUE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: Review, yahoo Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE_FIELD_VALUE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13992918#comment-13992918 ] ASF subversion and git services commented on TS-2636: - Commit 7f6f2709b3979462050ebd27ac68569b4dc68778 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7f6f270 ] Updated changes to include TS-2636 Enhance ATS custom logging to support WIPE_FIELD_VALUE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Yunkai Zhang Labels: Review, yahoo Fix For: 5.0.0 Attachments: ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Work started] (TS-2751) remove ProtocolNetAccept
[
https://issues.apache.org/jira/browse/TS-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-2751 started by James Peach.
remove ProtocolNetAccept
Key: TS-2751
URL: https://issues.apache.org/jira/browse/TS-2751
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: James Peach
Assignee: James Peach
Fix For: 5.0.0
We should remove {{ProtocolNetAccept}}. {{ProtocolNetAccept}} is used to
issue an initial read request so that the leading bytes of the client session
can be snooped to detect the protocol being issued by the client. However,
I'm pretty sure that this can be implemented directly by
{{ProtocolAcceptCont}} neé {{ProtocolDetectSessionAccept}} using the same
technique that is used for SSL NPN and ALPN. Additionally, we should remove
the probe state from {{UnixNetVConnection}}, which we can do either by adding
a peek operation to {{NetVConnection}}, or continuing to use {{do_io_read}},
but retaining the buffered data and passing that on to the client session
state that we subsequently spawn.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2787) custom logging field %csssc does not look right
[ https://issues.apache.org/jira/browse/TS-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mailbaoer updated TS-2787: -- Environment: centos 6.4 Affects Version/s: 4.0.2 custom logging field %csssc does not look right - Key: TS-2787 URL: https://issues.apache.org/jira/browse/TS-2787 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 4.0.2 Environment: centos 6.4 Reporter: mailbaoer when I use custom logging field %csssc，I found that does not look right： 1. TCP_MISS： return 200 2.TCP_HIT： return 000 like %csssc %crc %csshv%pssc 000 TCP_MISS HTTP/0.0200 000 TCP_MISS HTTP/0.0 200 000 TCP_REFRESH_MISS HTTP/0.0200 200 TCP_HIT HTTP/1.1200 200 TCP_MEM_HIT GET HTTP/1.1200 my environment is chrome，everytime use ctrl+f5 to refresh -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2796) Leaking CacheVConnections
[ https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2796: - Description: It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. was: It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. Leaking CacheVConnections - Key: TS-2796 URL: https://issues.apache.org/jira/browse/TS-2796 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2, 4.2.1, 5.0.0 Reporter: Brian Geffon It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3]
[jira] [Commented] (TS-2751) remove ProtocolNetAccept
[
https://issues.apache.org/jira/browse/TS-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995212#comment-13995212
]
James Peach commented on TS-2751:
-
I'm working on this, and I have a partial patch.
remove ProtocolNetAccept
Key: TS-2751
URL: https://issues.apache.org/jira/browse/TS-2751
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: James Peach
Assignee: James Peach
Fix For: 5.0.0
We should remove {{ProtocolNetAccept}}. {{ProtocolNetAccept}} is used to
issue an initial read request so that the leading bytes of the client session
can be snooped to detect the protocol being issued by the client. However,
I'm pretty sure that this can be implemented directly by
{{ProtocolAcceptCont}} neé {{ProtocolDetectSessionAccept}} using the same
technique that is used for SSL NPN and ALPN. Additionally, we should remove
the probe state from {{UnixNetVConnection}}, which we can do either by adding
a peek operation to {{NetVConnection}}, or continuing to use {{do_io_read}},
but retaining the buffered data and passing that on to the client session
state that we subsequently spawn.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2796) Leaking CacheVConnections
Brian Geffon created TS-2796: Summary: Leaking CacheVConnections Key: TS-2796 URL: https://issues.apache.org/jira/browse/TS-2796 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Brian Geffon It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name |||-- 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2796) Leaking CacheVConnections
[
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995439#comment-13995439
]
Bryan Call commented on TS-2796:
Memory diff of a LinkedIn vs Yahoo production host:
{code}
name allocated in_use type_size
allocated(MB)
memory/ArenaBlock 786432 -54272 1024
0
memory/FetchSMAllocator 36864 0288
0
memory/RamCacheCLFUSEntry 364953600 364946400 96
348
memory/RamCacheLRUEntry -9601024 -9126016 64
-9
memory/cacheRemoveCont -6144 0 48
0
memory/cacheVConnection -9977856 -4804256928
-9
memory/dnsBufAllocator-135424 0 33856
0
memory/evacuationBlock-737280-737856 96
0
memory/evacuationKey -6144 0 48
0
memory/eventAllocator -73728 584832 96
0
memory/hdrStrHeap -26476544 -5216256 4096
-25
memory/httpClientSessionAlloca -48039936 -45016704656
-45
memory/httpSMAllocator -135473152 -105433456 9728
-129
memory/httpServerSessionAlloca 143360 382816224
0
memory/ioAllocator -18800640 -17246160240
-17
memory/ioBlockAllocator -9543680 -8705600 64
-9
memory/ioBufAllocator[0]-131072 0128
0
memory/ioBufAllocator[10] 264241152 -626130944 131072
252
memory/ioBufAllocator[11] 6526337024 -537133056 262144
6224
memory/ioBufAllocator[12] 4093640704 -545783808 524288
3904
memory/ioBufAllocator[13] -805306368 -6427770881048576
-768
memory/ioBufAllocator[2] -65536 0512
0
memory/ioBufAllocator[3]-131072 0 1024
0
memory/ioBufAllocator[4] -2359296 -8192 2048
-2
memory/ioBufAllocator[5] -585105408 -542396416 4096
-558
memory/ioBufAllocator[6] 6397624320 6433579008 8192
6101
memory/ioBufAllocator[7]1431358668814380695552 16384
13650
memory/ioBufAllocator[8] 9016705024 4105961472 32768
8599
memory/ioBufAllocator[9] 3965714432 -621150208 65536
3782
memory/ioDataAllocator 77807616 78438960 48
74
memory/mutexAllocator -6225920 -5812000 80
-5
memory/netVCAllocator -17719296 -15882048672
-16
memory/openDirEntry -1822720 -1109280160
-1
memory/sslNetVCAllocator -43683840 -37772640720
-41
{code}
Leaking CacheVConnections
-
Key: TS-2796
URL: https://issues.apache.org/jira/browse/TS-2796
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.2, 4.2.1, 5.0.0
Reporter: Brian Geffon
Labels: yahoo
Fix For: 5.0.0
It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking
CacheVConnections resulting in IOBufAllocator leaking also, here is an
example:
allocated |in-use | type size | free list name
67108864 | 0 |2097152 |
memory/ioBufAllocator[14]
67108864 | 19922944 |1048576 |
memory/ioBufAllocator[13]
4798283776 | 14155776 | 524288 |
memory/ioBufAllocator[12]
7281311744 | 98304000 | 262144 |
memory/ioBufAllocator[11]
1115684864 | 148242432 | 131072 |
memory/ioBufAllocator[10]
497544 | 379977728 | 65536 |
memory/ioBufAllocator[9]
9902751744 | 5223546880 | 32768 |
memory/ioBufAllocator[8]
14762901504 |14762311680 | 16384 |
memory/ioBufAllocator[7]
6558056448 | 6557859840 | 8192 |
memory/ioBufAllocator[6]
41418752 | 30502912 | 4096 |
memory/ioBufAllocator[5]
[jira] [Comment Edited] (TS-2796) Leaking CacheVConnections
[
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995394#comment-13995394
]
Thomas Jackson edited comment on TS-2796 at 5/12/14 7:33 PM:
-
We're running ATS 4.2.1 and we are seeing this leaking pretty fast (~1gb of an
hour). Memory
{code}
2138112 |2124192 |928 | memory/cacheVConnection
{code}
was (Author: jacksontj):
We're running ATS 4.2.1 and we are seeing this leaking pretty fast (~1gb of an
hour). Memory
{code}
2138112 |2124192 |928 | memory/cacheVConnection
{code
Leaking CacheVConnections
-
Key: TS-2796
URL: https://issues.apache.org/jira/browse/TS-2796
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.2, 4.2.1, 5.0.0
Reporter: Brian Geffon
Labels: yahoo
Fix For: 5.0.0
It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking
CacheVConnections resulting in IOBufAllocator leaking also, here is an
example:
allocated |in-use | type size | free list name
67108864 | 0 |2097152 |
memory/ioBufAllocator[14]
67108864 | 19922944 |1048576 |
memory/ioBufAllocator[13]
4798283776 | 14155776 | 524288 |
memory/ioBufAllocator[12]
7281311744 | 98304000 | 262144 |
memory/ioBufAllocator[11]
1115684864 | 148242432 | 131072 |
memory/ioBufAllocator[10]
497544 | 379977728 | 65536 |
memory/ioBufAllocator[9]
9902751744 | 5223546880 | 32768 |
memory/ioBufAllocator[8]
14762901504 |14762311680 | 16384 |
memory/ioBufAllocator[7]
6558056448 | 6557859840 | 8192 |
memory/ioBufAllocator[6]
41418752 | 30502912 | 4096 |
memory/ioBufAllocator[5]
524288 | 0 | 2048 |
memory/ioBufAllocator[4]
0 | 0 | 1024 |
memory/ioBufAllocator[3]
0 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
0 | 0 |128 |
memory/ioBufAllocator[0]
2138112 |2124192 |928 |
memory/cacheVConnection
[~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x.
The code path in CacheVC that is allocating the IoBuffers is
memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom
the real issue here is the leaking CacheVC.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2795) Leaking CacheVConnections
Brian Geffon created TS-2795: Summary: Leaking CacheVConnections Key: TS-2795 URL: https://issues.apache.org/jira/browse/TS-2795 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Brian Geffon It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name |||-- 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2797) Not all manpages getting built
Jack Bates created TS-2797: -- Summary: Not all manpages getting built Key: TS-2797 URL: https://issues.apache.org/jira/browse/TS-2797 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Not all of the manpages are getting built because they are not part of the man_pages list in doc/conf.py This patch adds all of the files in the doc/reference/api directory to the list of manual pages. It also adds the manual page descriptions to the HTML output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[ https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2791: -- Attachment: ts2791.diff SPDY POST transactions failing with ERR_CLIENT_ABORT Key: TS-2791 URL: https://issues.apache.org/jira/browse/TS-2791 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2791.diff During our production testing of SPDY, we noticed that when trying to compose mails (POST transactions) on Firefox, we are seeing Network Error from the browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue appears to be likely specific to SPDY transactions and seem to be triggered by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer. After some investigation, it looks like this may be caused by a timing issue related to streaming of the POST data to the origin.. If the POST body (data) is available by the time client session and origin connection is ready, the POST is successful, but, if the data is large enough that it is not all read yet by the time origin connection is established, the streaming does not get triggered. Debugging further to identify the root cause. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995677#comment-13995677 ] ASF subversion and git services commented on TS-2555: - Commit 63400cb4f75873c92352eadecf4510d8893782da in trafficserver's branch refs/heads/master from [~kichan] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=63400cb ] TS-2555: fix TSMBuffer and TSMLoc allocation problem for client request in ts_lua plugin Move existing lua plugin to plugins/deprecated and rename ts_lua to lua --- Key: TS-2555 URL: https://issues.apache.org/jira/browse/TS-2555 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.0.0 As suggested by Igor Galic in TS-2335, to avoid namespace pollution, we could move move the old Lua plugin to plugins/deprecated, and name this one lua again from the start. From what I gather, the consensus on the mailing list was to replace the old plugin with this one. Given that the old plugin was experimental, and we've decided that all bets regarding compatibility and stability are off in experimental, I'm fairly certain we can just do that. I'd move it, for easy reference into plugins/deprecated, remove it from the build, and once the new plugin has absorbed all of its features, remove it all together. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2797) Not all manpages getting built
[ https://issues.apache.org/jira/browse/TS-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995657#comment-13995657 ] ASF GitHub Bot commented on TS-2797: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/82 Not all manpages getting built -- Key: TS-2797 URL: https://issues.apache.org/jira/browse/TS-2797 Project: Traffic Server Issue Type: Bug Components: Documentation Affects Versions: 5.0.0 Reporter: Jack Bates Assignee: James Peach Fix For: 5.0.0 Not all of the manpages are getting built because they are not part of the man_pages list in doc/conf.py This patch adds all of the files in the doc/reference/api directory to the list of manual pages. It also adds the manual page descriptions to the HTML output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2796) Leaking CacheVConnections
[
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995439#comment-13995439
]
Bryan Call edited comment on TS-2796 at 5/12/14 6:45 PM:
-
Memory diff of a LinkedIn vs Yahoo production host:
The values are LinkedIn host memory value - Yahoo host memory value and print
it if is was non-zero.
{code}
name allocated in_use type_size
allocated(MB)
memory/ArenaBlock 786432 -54272 1024
0
memory/FetchSMAllocator 36864 0288
0
memory/RamCacheCLFUSEntry 364953600 364946400 96
348
memory/RamCacheLRUEntry -9601024 -9126016 64
-9
memory/cacheRemoveCont -6144 0 48
0
memory/cacheVConnection -9977856 -4804256928
-9
memory/dnsBufAllocator-135424 0 33856
0
memory/evacuationBlock-737280-737856 96
0
memory/evacuationKey -6144 0 48
0
memory/eventAllocator -73728 584832 96
0
memory/hdrStrHeap -26476544 -5216256 4096
-25
memory/httpClientSessionAlloca -48039936 -45016704656
-45
memory/httpSMAllocator -135473152 -105433456 9728
-129
memory/httpServerSessionAlloca 143360 382816224
0
memory/ioAllocator -18800640 -17246160240
-17
memory/ioBlockAllocator -9543680 -8705600 64
-9
memory/ioBufAllocator[0]-131072 0128
0
memory/ioBufAllocator[10] 264241152 -626130944 131072
252
memory/ioBufAllocator[11] 6526337024 -537133056 262144
6224
memory/ioBufAllocator[12] 4093640704 -545783808 524288
3904
memory/ioBufAllocator[13] -805306368 -6427770881048576
-768
memory/ioBufAllocator[2] -65536 0512
0
memory/ioBufAllocator[3]-131072 0 1024
0
memory/ioBufAllocator[4] -2359296 -8192 2048
-2
memory/ioBufAllocator[5] -585105408 -542396416 4096
-558
memory/ioBufAllocator[6] 6397624320 6433579008 8192
6101
memory/ioBufAllocator[7]1431358668814380695552 16384
13650
memory/ioBufAllocator[8] 9016705024 4105961472 32768
8599
memory/ioBufAllocator[9] 3965714432 -621150208 65536
3782
memory/ioDataAllocator 77807616 78438960 48
74
memory/mutexAllocator -6225920 -5812000 80
-5
memory/netVCAllocator -17719296 -15882048672
-16
memory/openDirEntry -1822720 -1109280160
-1
memory/sslNetVCAllocator -43683840 -37772640720
-41
{code}
was (Author: bcall):
Memory diff of a LinkedIn vs Yahoo production host:
{code}
name allocated in_use type_size
allocated(MB)
memory/ArenaBlock 786432 -54272 1024
0
memory/FetchSMAllocator 36864 0288
0
memory/RamCacheCLFUSEntry 364953600 364946400 96
348
memory/RamCacheLRUEntry -9601024 -9126016 64
-9
memory/cacheRemoveCont -6144 0 48
0
memory/cacheVConnection -9977856 -4804256928
-9
memory/dnsBufAllocator-135424 0 33856
0
memory/evacuationBlock-737280-737856 96
0
memory/evacuationKey -6144 0 48
0
memory/eventAllocator -73728 584832 96
0
memory/hdrStrHeap -26476544 -5216256 4096
-25
memory/httpClientSessionAlloca -48039936 -45016704656
-45
memory/httpSMAllocator
[jira] [Updated] (TS-2796) Leaking CacheVConnections
[ https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2796: - Description: It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. The code path in CacheVC that is allocating the IoBuffers is memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom the real issue here is the leaking CacheVC. was: It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. Leaking CacheVConnections - Key: TS-2796 URL: https://issues.apache.org/jira/browse/TS-2796 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2, 4.2.1, 5.0.0 Reporter: Brian Geffon It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 |
[jira] [Commented] (TS-1475) static analysis: clean up all clang and coverity reports
[ https://issues.apache.org/jira/browse/TS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995283#comment-13995283 ] ASF subversion and git services commented on TS-1475: - Commit c7df50254c98b1cd301a148730824184c5e755bb in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c7df502 ] TS-1475 Avoid clang warnings on Dead store / increment static analysis: clean up all clang and coverity reports Key: TS-1475 URL: https://issues.apache.org/jira/browse/TS-1475 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 3.3.0 Reporter: Zhao Yongming Fix For: 6.0.0 the new report is in http://people.apache.org/~igalic/checks/ats/latest/ and I will open more sub tasks -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2799) SPDY negotates SPDY/3 only
[ https://issues.apache.org/jira/browse/TS-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2799: -- Attachment: Screenshot 2014-05-12 at 05.04.01 PM.png SPDY negotates SPDY/3 only -- Key: TS-2799 URL: https://issues.apache.org/jira/browse/TS-2799 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Fix For: sometime Attachments: Screenshot 2014-05-12 at 05.04.01 PM.png According to my Chrome, our SPDY implementation negotiates SPDY/3, even though /3.1 is supposed to be supported. I checked against Google, which successfully negotiates /3.1. See attached screenshot for an example. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2798) Cannot reload SSL client config. It appears to but does not work.
Greg Henry created TS-2798: -- Summary: Cannot reload SSL client config. It appears to but does not work. Key: TS-2798 URL: https://issues.apache.org/jira/browse/TS-2798 Project: Traffic Server Issue Type: Bug Components: Configuration, SSL Reporter: Greg Henry Cannot reload SSL client config. It appears to but does not work. Made changes to reflect a Cert file. It would not work without a complete restart of ATS. Should have been a traffic_line -x -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2800) SPDY session (keep-alive) timeouts is too low and not configurable
[ https://issues.apache.org/jira/browse/TS-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2800: -- Fix Version/s: sometime SPDY session (keep-alive) timeouts is too low and not configurable Key: TS-2800 URL: https://issues.apache.org/jira/browse/TS-2800 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Leif Hedstrom Fix For: sometime The default timeout on our SPDY sessions is way to short by default (30s), and also not configurable. I think we should 1. Create a new configuration (following our other timeout naming conventions) for SPDY inactivity / active timeouts. 2. Increase the defaults to be much higher. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2799) SPDY negotates SPDY/3 only
Leif Hedstrom created TS-2799: - Summary: SPDY negotates SPDY/3 only Key: TS-2799 URL: https://issues.apache.org/jira/browse/TS-2799 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Attachments: Screenshot 2014-05-12 at 05.04.01 PM.png According to my Chrome, our SPDY implementation negotiates SPDY/3, even though /3.1 is supposed to be supported. I checked against Google, which successfully negotiates /3.1. See attached screenshot for an example. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2730) proxy.config.cache.enable_read_while_writer
[ https://issues.apache.org/jira/browse/TS-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2730: -- Fix Version/s: sometime Moving out to sometime, I don't think either of these will be worked on for v5.0.0. But, feel free to set an appropriate release version for these. proxy.config.cache.enable_read_while_writer Key: TS-2730 URL: https://issues.apache.org/jira/browse/TS-2730 Project: Traffic Server Issue Type: Bug Components: Cache, Configuration Reporter: Faysal Banna Fix For: sometime Hi Guys ATS version 4.2.0 I have enabled proxy.config.cache.enable_read_while_writer and made sure the background fill threshold and timeout set to proper values and did some tests that will show u here below : two terminals opened: On terminal 1 : wget -S -c --delete-after 'http://www.golang-book.com/assets/pdf/gobook.pdf' --2014-04-18 15:41:47-- http://www.golang-book.com/assets/pdf/gobook.pdf Connecting to 212.98.152.163:8080... connected. Proxy request sent, awaiting response... HTTP/1.1 200 OK Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: application/pdf Accept-Ranges: bytes Date: Fri, 18 Apr 2014 12:37:46 GMT Server: ATS/4.2.0 Alternate-Protocol: 80:quic,80:quic Content-Length: 2893557 Age: 28758 Proxy-Connection: keep-alive Via: http/1.1 UB1-UTU3-170413 (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t cCMi p sS]) Length: 2893557 (2.8M) [application/pdf] Saving to: ‘gobook.pdf’ 20% [= ] 602,463 18.7KB/s eta 2m 5s after waiting couple of seconds i opened terminal 2 and issued : wget -S -c --delete-after 'http://www.golang-book.com/assets/pdf/gobook.pdf' --2014-04-18 15:41:59-- http://www.golang-book.com/assets/pdf/gobook.pdf Connecting to 212.98.152.163:8080... connected. Proxy request sent, awaiting response... HTTP/1.1 200 OK Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: application/pdf Accept-Ranges: bytes Date: Fri, 18 Apr 2014 12:37:46 GMT Server: ATS/4.2.0 Alternate-Protocol: 80:quic,80:quic Content-Length: 2893557 Age: 28772 Proxy-Connection: keep-alive Via: http/1.1 UB1-UTU3-170413 (ApacheTrafficServer/4.2.0 [uScMsSf pSeN:t cCMi p sS]) Length: 2893557 (2.8M) [application/pdf] Saving to: ‘gobook.pdf’ 11% [= ] 325,864 18.5KB/s eta 2m 53s and thus as it shows the read_while_writer is not working as it is supposed the least i should get the first already downloaded chunks in network speed and that didn't happen. second thing is that and i confirm that after aborting both terminals before any of them would even complete and waited couple of moments i issued on a new terminal the same request wget -S -c --delete-after 'http://www.golang-book.com/assets/pdf/gobook.pdf' --2014-04-18 15:52:08-- http://www.golang-book.com/assets/pdf/gobook.pdf Connecting to 212.98.152.163:8080... connected. Proxy request sent, awaiting response... HTTP/1.1 206 Partial Content Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: application/pdf Accept-Ranges: bytes Date: Fri, 18 Apr 2014 12:37:46 GMT Server: ATS/4.2.0 Alternate-Protocol: 80:quic,80:quic Content-Length: 2566130 Age: 29379 Content-Range: bytes 327427-2893556/2893557 Proxy-Connection: keep-alive Via: http/1.1 UB1-UTU3-170413 (ApacheTrafficServer/4.2.0 [uScHs f p eN:t cCHi p s ]) Length: 2893557 (2.8M), 2566130 (2.4M) remaining [application/pdf] Saving to: ‘gobook.pdf’ 100%[++] 2,893,557 2.03MB/s in 1.2s 2014-04-18 15:52:09 (2.03 MB/s) - ‘gobook.pdf’ saved [2893557/2893557] which means that the background fill works as intended but read while_writer does not at all. much regards i am going to install 4.2.1 and see if the same behavior happens again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2781) orphan log Unreasonable when first logserver down at runtime
[ https://issues.apache.org/jira/browse/TS-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2781: -- Fix Version/s: sometime Moving out to sometime, I don't think either of these will be worked on for v5.0.0. But, feel free to set an appropriate release version for these. orphan log Unreasonable when first logserver down at runtime - Key: TS-2781 URL: https://issues.apache.org/jira/browse/TS-2781 Project: Traffic Server Issue Type: Bug Affects Versions: 4.2.0 Reporter: bettydramit Fix For: sometime my logs_xml.config CollationHosts=172.16.2.53:8085|172.16.10.53:8085/ 172.16.2.53 is down 172.16.10.53 is alive When start ats, 172.16.2.53 orphan log write to local disk. The diags.log shown 172.16.10.53 log up -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2801: -- Fix Version/s: sometime Enabling SPDY can cause page corruptions Key: TS-2801 URL: https://issues.apache.org/jira/browse/TS-2801 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Fix For: sometime Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png When I build ATS with SPDY support, I see (sometimes) severe page corruptions on my site. What's even odd, these corruptions happens even more frequently from browsers which do not support SPDY. Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is no long corrupted. See the attached screenschot from a corruption from https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2801) Enabling SPDY can cause page corruptions
Leif Hedstrom created TS-2801: - Summary: Enabling SPDY can cause page corruptions Key: TS-2801 URL: https://issues.apache.org/jira/browse/TS-2801 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png When I build ATS with SPDY support, I see (sometimes) severe page corruptions on my site. What's even odd, these corruptions happens even more frequently from browsers which do not support SPDY. Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is no long corrupted. See the attached screenschot from a corruption from https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2725) When using the transform in the plugins, the query results from traffic_line is incorrect
[ https://issues.apache.org/jira/browse/TS-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2725: -- Fix Version/s: sometime Moving out to sometime, I don't think either of these will be worked on for v5.0.0. But, feel free to set an appropriate release version for these. When using the transform in the plugins, the query results from traffic_line is incorrect - Key: TS-2725 URL: https://issues.apache.org/jira/browse/TS-2725 Project: Traffic Server Issue Type: Bug Components: Metrics Affects Versions: 4.2.0 Environment: centos6 Reporter: acache Fix For: sometime When using the transform in the plugins, the query results from traffic_line is incorrect. Add a transform hook in read response hook. For example,proxy.node.http.origin_server_total_response_bytes will becomes very slow growth when using any transform in the plugins. test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M Tsar is a tool,qurey results by traffic_line. [root@ats plugins]# http_load -proxy 127.0.0.1:8080 -p 50 -seconds 120 /root/test.txt [root@ats plugins]#cat /root/test.txt http://127.0.0.1/vlive.qqvideo.tc.qq.com/2.mp4 the results using transform(used example/null-transform,do nothing): [root@ats plugins]# tsar --ts --ts_os -l ts----ts_os qps Bps qps Bps 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.00 107.2M 4.00 915.80 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts --ts_os qps Bps qps Bps 25.60 716.3M 25.60 716.3M 24.60 693.7M 24.60 693.7M 25.20 705.0M 25.20 705.0M 24.80 699.4M 24.80 699.4M 25.60 716.3M 25.60 716.3M 25.00 705.0M 25.00 705.0M 25.40 710.7M 25.40 710.7M 24.80 699.4M 24.80 699.4M 25.00 699.4M 25.00 699.4M 24.60 693.7M 24.60 693.7M ``` -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2440) ATS 3.2.0 keeps restarting after adding a node to the cluster (not the same as TS-1511)
[
https://issues.apache.org/jira/browse/TS-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2440:
--
Fix Version/s: sometime
Moving out to sometime, I don't think either of these will be worked on for
v5.0.0. But, feel free to set an appropriate release version for these.
ATS 3.2.0 keeps restarting after adding a node to the cluster (not the same
as TS-1511)
---
Key: TS-2440
URL: https://issues.apache.org/jira/browse/TS-2440
Project: Traffic Server
Issue Type: Bug
Components: Cache, Clustering
Reporter: Kamil Abboud
Labels: Crash
Fix For: sometime
Hi all,
We have two nodes installed with ATS3.2.0 running on RHEL6.2.
When we start the second node (in full clustering mode) the system works for
~5-10 minutes and the traffic server process crashes giving the following
stacktrace:
{code}
#0 0x00360cd372a0 in __memcpy_ssse3 () from /lib64/libc.so.6
#1 0x005b3521 in HdrHeap::marshal(char*, int) ()
#2 0x005b73a1 in HTTPInfo::marshal(char*, int) ()
#3 0x005fda19 in CacheContinuation::replyOpEvent(int, VConnection*)
()
#4 0x005fa677 in CacheContinuation::VCdataRead(int, VIO*) ()
#5 0x0064683c in CacheVC::openReadMain(int, Event*) ()
#6 0x0064520b in CacheVC::callcont ()
#7 0x00648896 in CacheVC::openReadStartEarliest(int, Event*) ()
#8 0x0062540d in CacheVC::handleReadDone(int, Event*) ()
#9 0x0062a295 in AIOCallbackInternal::io_complete(int, void*) ()
#10 0x00696c04 in EThread::process_event(Event*, int) ()
#11 0x0069767b in EThread::execute() ()
#12 0x00695bd2 in spawn_thread_internal(void*) ()
#13 0x00360d0077f1 in start_thread () from /lib64/libpthread.so.0
#14 0x00360cce570d in clone () from /lib64/libc.so.6
{code}
Please note that the system we are working with has the following Fixes on it:
- TS-1424
- TS-1151
- TS-1580
- TS-2092
- TS-2264
Thanks,
Kamil
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2496) Null transform plugin set 50% bandwidth capcability
[ https://issues.apache.org/jira/browse/TS-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2496: -- Fix Version/s: sometime Moving out to sometime, I don't think either of these will be worked on for v5.0.0. But, feel free to set an appropriate release version for these. Null transform plugin set 50% bandwidth capcability --- Key: TS-2496 URL: https://issues.apache.org/jira/browse/TS-2496 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Roee Gil Fix For: sometime Attachments: speedTestNoTransform.png, speedTestWithTransform.png When using null transform example (as is), I get bandwidth capacity reduced to half and worst. testing the connection speed at: http://www.speedtest.net/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2769) Can we eliminate boost dependency in libtsconfig ?
[ https://issues.apache.org/jira/browse/TS-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2769: -- Fix Version/s: sometime Moving out to sometime, I don't think either of these will be worked on for v5.0.0. But, feel free to set an appropriate release version for these. Can we eliminate boost dependency in libtsconfig ? -- Key: TS-2769 URL: https://issues.apache.org/jira/browse/TS-2769 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Fix For: sometime Similarly, we plan on eliminating boost from header_rewrite. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2802) Add SNI support for origin servers
[
https://issues.apache.org/jira/browse/TS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2802:
---
Fix Version/s: sometime
Add SNI support for origin servers
--
Key: TS-2802
URL: https://issues.apache.org/jira/browse/TS-2802
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Bryan Call
Fix For: sometime
test to an origin that requires SNI
{code}
[bcall@cat ~]$ tail -1 /usr/local/etc/trafficserver/remap.config
map http://foo.yahoo.com
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
[bcall@cat ~]$ curl -H 'Host: foo.yahoo.com' http://localhost:8080/; echo
TLS SNI Required.
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[ https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995842#comment-13995842 ] Sudheer Vinukonda commented on TS-2791: --- Hi, Leif - Unfortunately, this is a blocker for our SPDY Q2 goal, so, we need this fix urgently. I've tested a fix for this already and attached the patch here. Bryan will help review and commit this to 5.0. Regards, Sudheer SPDY POST transactions failing with ERR_CLIENT_ABORT Key: TS-2791 URL: https://issues.apache.org/jira/browse/TS-2791 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Fix For: sometime Attachments: ts2791.diff During our production testing of SPDY, we noticed that when trying to compose mails (POST transactions) on Firefox, we are seeing Network Error from the browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue appears to be likely specific to SPDY transactions and seem to be triggered by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer. After some investigation, it looks like this may be caused by a timing issue related to streaming of the POST data to the origin.. If the POST body (data) is available by the time client session and origin connection is ready, the POST is successful, but, if the data is large enough that it is not all read yet by the time origin connection is established, the streaming does not get triggered. Debugging further to identify the root cause. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2798) Cannot reload SSL client config. It appears to but does not work.
[ https://issues.apache.org/jira/browse/TS-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2798: -- Fix Version/s: sometime Cannot reload SSL client config. It appears to but does not work. -- Key: TS-2798 URL: https://issues.apache.org/jira/browse/TS-2798 Project: Traffic Server Issue Type: Bug Components: Configuration, SSL Reporter: Greg Henry Fix For: sometime Cannot reload SSL client config. It appears to but does not work. Made changes to reflect a Cert file. It would not work without a complete restart of ATS. Should have been a traffic_line -x -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2529) Create wrapper function for dlerror() to handle the return of const char* on FreeBSD 8.1 and OpenBSD
[
https://issues.apache.org/jira/browse/TS-2529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2529:
--
Fix Version/s: sometime
Moving out to sometime, I don't think either of these will be worked on for
v5.0.0. But, feel free to set an appropriate release version for these.
Create wrapper function for dlerror() to handle the return of const char* on
FreeBSD 8.1 and OpenBSD
--
Key: TS-2529
URL: https://issues.apache.org/jira/browse/TS-2529
Project: Traffic Server
Issue Type: Bug
Components: Cleanup
Reporter: Igor Galić
Fix For: sometime
{code}
#if defined(freebsd) || defined(openbsd)
err = (char *)dlerror();
#else
err = dlerror();
#endif
{code}
Why is this #if dance necessary here?
http://www.freebsd.org/cgi/man.cgi?dlerror dlerror() hasn't been const char*
since FreeBSD 8.1. In OpenBSD it's still *is* ...broken, but then we should
abstract that into a wrapper function of our own at autoconf time.
We're not handling this case at every call of dlerror() anyways.. so
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2796) Leaking CacheVConnections
[
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995894#comment-13995894
]
Alan M. Carroll commented on TS-2796:
-
Maybe check {{HTTPCacheAlt::copy_frag_offsets_from}} to verify that
{{m_frag_offsets}} is {{NULL}} before the copy. I think that should always be
true but perhaps not.
Leaking CacheVConnections
-
Key: TS-2796
URL: https://issues.apache.org/jira/browse/TS-2796
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.2, 4.2.1, 5.0.0
Reporter: Brian Geffon
Labels: yahoo
Fix For: 5.0.0
It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking
CacheVConnections resulting in IOBufAllocator leaking also, here is an
example:
allocated |in-use | type size | free list name
67108864 | 0 |2097152 |
memory/ioBufAllocator[14]
67108864 | 19922944 |1048576 |
memory/ioBufAllocator[13]
4798283776 | 14155776 | 524288 |
memory/ioBufAllocator[12]
7281311744 | 98304000 | 262144 |
memory/ioBufAllocator[11]
1115684864 | 148242432 | 131072 |
memory/ioBufAllocator[10]
497544 | 379977728 | 65536 |
memory/ioBufAllocator[9]
9902751744 | 5223546880 | 32768 |
memory/ioBufAllocator[8]
14762901504 |14762311680 | 16384 |
memory/ioBufAllocator[7]
6558056448 | 6557859840 | 8192 |
memory/ioBufAllocator[6]
41418752 | 30502912 | 4096 |
memory/ioBufAllocator[5]
524288 | 0 | 2048 |
memory/ioBufAllocator[4]
0 | 0 | 1024 |
memory/ioBufAllocator[3]
0 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
0 | 0 |128 |
memory/ioBufAllocator[0]
2138112 |2124192 |928 |
memory/cacheVConnection
[~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x.
The code path in CacheVC that is allocating the IoBuffers is
memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom
the real issue here is the leaking CacheVC.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[
https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995943#comment-13995943
]
Bryan Call commented on TS-2791:
[~sudheerv]
Did you try set TS_FETCH_FLAGS_STREAM? I would like to know more details about
why header_done is not being set.
{code}
if (header_done == 0 ((fetch_flags TS_FETCH_FLAGS_STREAM) ||
callback_options == AFTER_HEADER)) {
if (client_response_hdr.parse_resp(http_parser, resp_reader,
bytes_used, 0) == PARSE_DONE) {
header_done = 1;
{code}
SPDY POST transactions failing with ERR_CLIENT_ABORT
Key: TS-2791
URL: https://issues.apache.org/jira/browse/TS-2791
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: spdy, yahoo
Fix For: sometime
Attachments: ts2791.diff
During our production testing of SPDY, we noticed that when trying to compose
mails (POST transactions) on Firefox, we are seeing Network Error from the
browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue
appears to be likely specific to SPDY transactions and seem to be triggered
by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer.
After some investigation, it looks like this may be caused by a timing issue
related to streaming of the POST data to the origin.. If the POST body (data)
is available by the time client session and origin connection is ready, the
POST is successful, but, if the data is large enough that it is not all read
yet by the time origin connection is established, the streaming does not get
triggered. Debugging further to identify the root cause.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[
https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995943#comment-13995943
]
Bryan Call edited comment on TS-2791 at 5/13/14 2:01 AM:
-
[~sudheerv]
Did you try to set TS_FETCH_FLAGS_STREAM? I would like to know more details
about why header_done is not being set.
{code}
if (header_done == 0 ((fetch_flags TS_FETCH_FLAGS_STREAM) ||
callback_options == AFTER_HEADER)) {
if (client_response_hdr.parse_resp(http_parser, resp_reader,
bytes_used, 0) == PARSE_DONE) {
header_done = 1;
{code}
was (Author: bcall):
[~sudheerv]
Did you try set TS_FETCH_FLAGS_STREAM? I would like to know more details about
why header_done is not being set.
{code}
if (header_done == 0 ((fetch_flags TS_FETCH_FLAGS_STREAM) ||
callback_options == AFTER_HEADER)) {
if (client_response_hdr.parse_resp(http_parser, resp_reader,
bytes_used, 0) == PARSE_DONE) {
header_done = 1;
{code}
SPDY POST transactions failing with ERR_CLIENT_ABORT
Key: TS-2791
URL: https://issues.apache.org/jira/browse/TS-2791
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: spdy, yahoo
Fix For: sometime
Attachments: ts2791.diff
During our production testing of SPDY, we noticed that when trying to compose
mails (POST transactions) on Firefox, we are seeing Network Error from the
browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue
appears to be likely specific to SPDY transactions and seem to be triggered
by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer.
After some investigation, it looks like this may be caused by a timing issue
related to streaming of the POST data to the origin.. If the POST body (data)
is available by the time client session and origin connection is ready, the
POST is successful, but, if the data is large enough that it is not all read
yet by the time origin connection is established, the streaming does not get
triggered. Debugging further to identify the root cause.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2796) Leaking CacheVConnections
[ https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995956#comment-13995956 ] Zhao Yongming commented on TS-2796: --- I don't know what is this issue looking for, if we focus on the last line of memory dump, the memory/cacheVConnection, please ignore my comment. the most of the memory leaking in your memory dump result is memory/ioBufAllocator size 32K. and from what I can guess, you are using the defualt CLFUS ram cache algorithm, which will produce this effect when the system running a long time, and the big objects in memory is replaced by the smaller ones, but memory used by big objects is not released to the system yet. and that issue is already adressed in TS-1006, and result in the reclaimable freelist memory management codes, already shiped in 4.0 releases, with a configure options to enable. so, if this is the cause, please help verify that your problem is still there with reclaimable freelist enabled, and you may test the simple LRU algorithm in the ram cache too. thanks Leaking CacheVConnections - Key: TS-2796 URL: https://issues.apache.org/jira/browse/TS-2796 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2, 4.2.1, 5.0.0 Reporter: Brian Geffon Labels: yahoo Fix For: 5.0.0 It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. The code path in CacheVC that is allocating the IoBuffers is memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom the real issue here is the leaking CacheVC. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[ https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995975#comment-13995975 ] Sudheer Vinukonda commented on TS-2791: --- Hi Bryan - TS_FETCH_FLAGS_STREAM is already set during FetchSM initialization (FetchSM::ext_init) - I've confirmed this with debug logs as well. From what I can see, the flag header_done appears to be needed when sending response to a client (based on the way it is set by checking client_response_hdr.parse_resp()) . For sending a client request to the origin (that involves POST/PUT), header_done is probably not applicable. SPDY POST transactions failing with ERR_CLIENT_ABORT Key: TS-2791 URL: https://issues.apache.org/jira/browse/TS-2791 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Fix For: sometime Attachments: ts2791.diff During our production testing of SPDY, we noticed that when trying to compose mails (POST transactions) on Firefox, we are seeing Network Error from the browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue appears to be likely specific to SPDY transactions and seem to be triggered by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer. After some investigation, it looks like this may be caused by a timing issue related to streaming of the POST data to the origin.. If the POST body (data) is available by the time client session and origin connection is ready, the POST is successful, but, if the data is large enough that it is not all read yet by the time origin connection is established, the streaming does not get triggered. Debugging further to identify the root cause. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Work started] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-2723 started by Kit Chan. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2800) SPDY session (keep-alive) timeouts is too low and not configurable
Leif Hedstrom created TS-2800: - Summary: SPDY session (keep-alive) timeouts is too low and not configurable Key: TS-2800 URL: https://issues.apache.org/jira/browse/TS-2800 Project: Traffic Server Issue Type: New Feature Components: SPDY Reporter: Leif Hedstrom The default timeout on our SPDY sessions is way to short by default (30s), and also not configurable. I think we should 1. Create a new configuration (following our other timeout naming conventions) for SPDY inactivity / active timeouts. 2. Increase the defaults to be much higher. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2801: -- Attachment: Screenshot 2014-05-12 at 05.06.15 PM.png Enabling SPDY can cause page corruptions Key: TS-2801 URL: https://issues.apache.org/jira/browse/TS-2801 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Fix For: sometime Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png When I build ATS with SPDY support, I see (sometimes) severe page corruptions on my site. What's even odd, these corruptions happens even more frequently from browsers which do not support SPDY. Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is no long corrupted. See the attached screenschot from a corruption from https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2725) When using the transform in the plugins, the query results from traffic_line is incorrect
[ https://issues.apache.org/jira/browse/TS-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] acache updated TS-2725: --- Description: When using the transform in the plugins, the query results from traffic_line is incorrect. For example,add a transform hook in read response hook,then proxy.node.http.origin_server_total_response_bytes will becomes very slow growth when using any transform in the plugins. test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M Tsar is a tool,qurey results by traffic_line. [root@ats plugins]# http_load -proxy 127.0.0.1:8080 -p 50 -seconds 120 /root/test.txt [root@ats plugins]#cat /root/test.txt http://127.0.0.1/vlive.qqvideo.tc.qq.com/2.mp4 the results using transform(used example/null-transform,do nothing): [root@ats plugins]# tsar --ts --ts_os -l ts----ts_os qps Bps qps Bps 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.00 107.2M 4.00 915.80 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts --ts_os qps Bps qps Bps 25.60 716.3M 25.60 716.3M 24.60 693.7M 24.60 693.7M 25.20 705.0M 25.20 705.0M 24.80 699.4M 24.80 699.4M 25.60 716.3M 25.60 716.3M 25.00 705.0M 25.00 705.0M 25.40 710.7M 25.40 710.7M 24.80 699.4M 24.80 699.4M 25.00 699.4M 25.00 699.4M 24.60 693.7M 24.60 693.7M ``` was: When using the transform in the plugins, the query results from traffic_line is incorrect. Add a transform hook in read response hook. For example,proxy.node.http.origin_server_total_response_bytes will becomes very slow growth when using any transform in the plugins. test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M Tsar is a tool,qurey results by traffic_line. [root@ats plugins]# http_load -proxy 127.0.0.1:8080 -p 50 -seconds 120 /root/test.txt [root@ats plugins]#cat /root/test.txt http://127.0.0.1/vlive.qqvideo.tc.qq.com/2.mp4 the results using transform(used example/null-transform,do nothing): [root@ats plugins]# tsar --ts --ts_os -l ts----ts_os qps Bps qps Bps 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.00 107.2M 4.00 915.80 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts --ts_os qps Bps qps Bps 25.60 716.3M 25.60 716.3M 24.60 693.7M 24.60 693.7M 25.20 705.0M 25.20 705.0M 24.80 699.4M 24.80 699.4M 25.60 716.3M 25.60 716.3M 25.00 705.0M 25.00 705.0M 25.40 710.7M 25.40 710.7M 24.80 699.4M 24.80 699.4M 25.00 699.4M 25.00 699.4M 24.60 693.7M 24.60 693.7M ``` When using the transform in the plugins, the query results from traffic_line is incorrect - Key: TS-2725 URL: https://issues.apache.org/jira/browse/TS-2725 Project: Traffic Server Issue Type: Bug Components: Metrics Affects Versions: 4.2.0 Environment: centos6 Reporter: acache Fix For: sometime When using the transform in the plugins, the query results from traffic_line is incorrect. For example,add a transform hook in read response hook,then proxy.node.http.origin_server_total_response_bytes will becomes very slow growth when using any transform in the plugins. test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M Tsar is a tool,qurey results by traffic_line. [root@ats plugins]# http_load -proxy 127.0.0.1:8080 -p 50 -seconds 120 /root/test.txt [root@ats plugins]#cat /root/test.txt http://127.0.0.1/vlive.qqvideo.tc.qq.com/2.mp4 the results using transform(used example/null-transform,do nothing): [root@ats plugins]# tsar --ts --ts_os -l ts----ts_os qps Bps qps Bps 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.00 107.2M 4.00 915.80 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts --ts_os qps Bps qps Bps 25.60 716.3M 25.60 716.3M 24.60 693.7M 24.60 693.7M 25.20 705.0M 25.20 705.0M 24.80 699.4M 24.80 699.4M 25.60
[jira] [Created] (TS-2802) Add SNI support for origin servers
Bryan Call created TS-2802:
--
Summary: Add SNI support for origin servers
Key: TS-2802
URL: https://issues.apache.org/jira/browse/TS-2802
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Bryan Call
test to an origin that requires SNI
{code}
[bcall@cat ~]$ tail -1 /usr/local/etc/trafficserver/remap.config
map http://foo.yahoo.com
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
[bcall@cat ~]$ curl -H 'Host: foo.yahoo.com' http://localhost:8080/; echo
TLS SNI Required.
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[ https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995604#comment-13995604 ] Sudheer Vinukonda commented on TS-2791: --- Adding a patch that sends TS_EVENT_VCONN_WRITE_READY everytime, there's POST data. SPDY POST transactions failing with ERR_CLIENT_ABORT Key: TS-2791 URL: https://issues.apache.org/jira/browse/TS-2791 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Sudheer Vinukonda Labels: spdy, yahoo Attachments: ts2791.diff During our production testing of SPDY, we noticed that when trying to compose mails (POST transactions) on Firefox, we are seeing Network Error from the browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue appears to be likely specific to SPDY transactions and seem to be triggered by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer. After some investigation, it looks like this may be caused by a timing issue related to streaming of the POST data to the origin.. If the POST body (data) is available by the time client session and origin connection is ready, the POST is successful, but, if the data is large enough that it is not all read yet by the time origin connection is established, the streaming does not get triggered. Debugging further to identify the root cause. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2796) Leaking CacheVConnections
[ https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995961#comment-13995961 ] Zhao Yongming commented on TS-2796: --- and if the recleamable freelist will help you, please help me promote it to be enabled by default Leaking CacheVConnections - Key: TS-2796 URL: https://issues.apache.org/jira/browse/TS-2796 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2, 4.2.1, 5.0.0 Reporter: Brian Geffon Labels: yahoo Fix For: 5.0.0 It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. The code path in CacheVC that is allocating the IoBuffers is memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom the real issue here is the leaking CacheVC. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2725) When using the transform in the plugins, the query results from traffic_line is incorrect
[ https://issues.apache.org/jira/browse/TS-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] acache updated TS-2725: --- Description: When using the transform in the plugins, the query results from traffic_line is incorrect. For example,add a transform at read response hook,then proxy.node.http.origin_server_total_response_bytes will becomes very slow growth when using any transform in the plugins. test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M Tsar is a tool,qurey results by traffic_line. [root@ats plugins]# http_load -proxy 127.0.0.1:8080 -p 50 -seconds 120 /root/test.txt [root@ats plugins]#cat /root/test.txt http://127.0.0.1/vlive.qqvideo.tc.qq.com/2.mp4 the results using transform(used example/null-transform,do nothing): [root@ats plugins]# tsar --ts --ts_os -l ts----ts_os qps Bps qps Bps 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.00 107.2M 4.00 915.80 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts --ts_os qps Bps qps Bps 25.60 716.3M 25.60 716.3M 24.60 693.7M 24.60 693.7M 25.20 705.0M 25.20 705.0M 24.80 699.4M 24.80 699.4M 25.60 716.3M 25.60 716.3M 25.00 705.0M 25.00 705.0M 25.40 710.7M 25.40 710.7M 24.80 699.4M 24.80 699.4M 25.00 699.4M 25.00 699.4M 24.60 693.7M 24.60 693.7M ``` was: When using the transform in the plugins, the query results from traffic_line is incorrect. For example,add a transform hook in read response hook,then proxy.node.http.origin_server_total_response_bytes will becomes very slow growth when using any transform in the plugins. test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M Tsar is a tool,qurey results by traffic_line. [root@ats plugins]# http_load -proxy 127.0.0.1:8080 -p 50 -seconds 120 /root/test.txt [root@ats plugins]#cat /root/test.txt http://127.0.0.1/vlive.qqvideo.tc.qq.com/2.mp4 the results using transform(used example/null-transform,do nothing): [root@ats plugins]# tsar --ts --ts_os -l ts----ts_os qps Bps qps Bps 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.00 107.2M 4.00 915.80 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts --ts_os qps Bps qps Bps 25.60 716.3M 25.60 716.3M 24.60 693.7M 24.60 693.7M 25.20 705.0M 25.20 705.0M 24.80 699.4M 24.80 699.4M 25.60 716.3M 25.60 716.3M 25.00 705.0M 25.00 705.0M 25.40 710.7M 25.40 710.7M 24.80 699.4M 24.80 699.4M 25.00 699.4M 25.00 699.4M 24.60 693.7M 24.60 693.7M ``` When using the transform in the plugins, the query results from traffic_line is incorrect - Key: TS-2725 URL: https://issues.apache.org/jira/browse/TS-2725 Project: Traffic Server Issue Type: Bug Components: Metrics Affects Versions: 4.2.0 Environment: centos6 Reporter: acache Fix For: sometime When using the transform in the plugins, the query results from traffic_line is incorrect. For example,add a transform at read response hook,then proxy.node.http.origin_server_total_response_bytes will becomes very slow growth when using any transform in the plugins. test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M Tsar is a tool,qurey results by traffic_line. [root@ats plugins]# http_load -proxy 127.0.0.1:8080 -p 50 -seconds 120 /root/test.txt [root@ats plugins]#cat /root/test.txt http://127.0.0.1/vlive.qqvideo.tc.qq.com/2.mp4 the results using transform(used example/null-transform,do nothing): [root@ats plugins]# tsar --ts --ts_os -l ts----ts_os qps Bps qps Bps 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.20 112.8M 4.20 964.00 3.80 107.2M 3.80 915.80 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.00 107.2M 4.00 915.80 4.00 112.8M 4.00 964.00 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.20 112.8M 4.20 964.00 4.20 118.4M 4.20 1.0K 4.00 107.2M 4.00 915.80 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts --ts_os qps Bps qps Bps 25.60 716.3M 25.60 716.3M 24.60 693.7M 24.60 693.7M 25.20 705.0M 25.20 705.0M 24.80 699.4M 24.80 699.4M 25.60 716.3M
[jira] [Updated] (TS-2726) Weighted scheduler algorithm for balancer plugin
[ https://issues.apache.org/jira/browse/TS-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2726: -- Fix Version/s: sometime Moving out to sometime, I don't think either of these will be worked on for v5.0.0. But, feel free to set an appropriate release version for these. Weighted scheduler algorithm for balancer plugin Key: TS-2726 URL: https://issues.apache.org/jira/browse/TS-2726 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Thibault Marquand Priority: Minor Fix For: sometime Balancer plugin have two mains balancing policy : round-robin or by hash (key, source address or asked url). I was looking for an other one : a weighted policy like weight round-robin. The idea is quit simple : Each server can be assigned a weight, an integer value or what ever that indicates the processing capacity. Servers with higher weights receive new connections first than those with less weights, and servers with higher weights get more connections than those with less weights and servers with equal weights get equal connections. Thank you ! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2406:
--
Fix Version/s: sometime
Moving out to sometime, I don't think either of these will be worked on for
v5.0.0. But, feel free to set an appropriate release version for these.
Sig 11: Segmentation fault
--
Key: TS-2406
URL: https://issues.apache.org/jira/browse/TS-2406
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 4.2.0
Reporter: Neddy
Labels: Crash
Fix For: sometime
Attachments: traffic.out.bak
I've noticed this today, still don't know why
[Nov 27 21:10:49.280] Manager {0x7f54eff15720} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Nov 28 07:53:42.853] Manager {0x7f54eff15720} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
How can I trace this?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2773) rewrite SSL certificate configuration
[
https://issues.apache.org/jira/browse/TS-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2773:
--
Fix Version/s: sometime
Moving out to sometime, I don't think either of these will be worked on for
v5.0.0. But, feel free to set an appropriate release version for these.
rewrite SSL certificate configuration
-
Key: TS-2773
URL: https://issues.apache.org/jira/browse/TS-2773
Project: Traffic Server
Issue Type: New Feature
Components: Configuration, SSL
Reporter: James Peach
Fix For: sometime
Currently, SSL certificate configuration is split across {{records.config}}
and {{ssl-multicert.config}}. This leads to awkward situations where you
can't enable client certificate validation for a particular server
certificate, and you can't add a SSL key passphrase dialog globally.
I'd like to unify the SSL configuration by pushing all the configuration
parameters down to {{records.config}} and allowing {{ssl-multicert.config}}
to override those settings. This would be logically similar to how
overridable configurations work for the TS API.
I plan to retain backwards compatibility with 4.x {{ssl-multicert.config}}
syntax. You would still need {{ssl-multicert.config}} to be able to configure
multiple SSL certificates.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2798) SSL client configuration is not really reloadable
[ https://issues.apache.org/jira/browse/TS-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2798: Summary: SSL client configuration is not really reloadable (was: Cannot reload SSL client config. It appears to but does not work.) The problem here is that while the SSL client configuration values are reloadable, the SSL client context itself is never reloaded. This means that you can reload configuration all day long but it won't actually do anything. SSL client configuration is not really reloadable - Key: TS-2798 URL: https://issues.apache.org/jira/browse/TS-2798 Project: Traffic Server Issue Type: Bug Components: Configuration, SSL Reporter: Greg Henry Fix For: sometime Cannot reload SSL client config. It appears to but does not work. Made changes to reflect a Cert file. It would not work without a complete restart of ATS. Should have been a traffic_line -x -- This message was sent by Atlassian JIRA (v6.2#6252)
