[jira] [Created] (TS-2724) purge waste memory
bettydramit created TS-2724: --- Summary: purge waste memory Key: TS-2724 URL: https://issues.apache.org/jira/browse/TS-2724 Project: Traffic Server Issue Type: Bug Reporter: bettydramit I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M I set ats proxy.config.cache.target_fragment_size INT 1048576 I use curl to get them : for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done very file just get once, i can see ats memory usage is 138M After i use curl to purge them : for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done I can see ats memory usage is 246M very file removed from ats, why the memory usage enlarge about 100M -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2724) purge waste memory
[ https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-2724: Description: I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M records.config {code} proxy.config.cache.target_fragment_size INT 1048576 {code} I use curl to get them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done {code} every file just get once, i can see ats memory usage is 138M After use curl to purge them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done {code} I can see ats memory usage is 246M every file removed from ats, why the memory usage enlarge about 100M was: I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M records.config {code} proxy.config.cache.target_fragment_size INT 1048576 {code} I use curl to get them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done {code} every file just get once, i can see ats memory usage is 138M After use curl to purge them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done {code} I can see ats memory usage is 246M every file removed from ats, why the memory usage enlarge about 100M purge waste memory -- Key: TS-2724 URL: https://issues.apache.org/jira/browse/TS-2724 Project: Traffic Server Issue Type: Bug Reporter: bettydramit I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M records.config {code} proxy.config.cache.target_fragment_size INT 1048576 {code} I use curl to get them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done {code} every file just get once, i can see ats memory usage is 138M After use curl to purge them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done {code} I can see ats memory usage is 246M every file removed from ats, why the memory usage enlarge about 100M -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2724) purge waste memory
[ https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-2724: Description: I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M records.config {code} proxy.config.cache.target_fragment_size INT 1048576 {code} I use curl to get them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done {code} every file just get once, i can see ats memory usage is 138M After use curl to purge them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done {code} I can see ats memory usage is 246M every file removed from ats, why the memory usage enlarge about 100M was: I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M I set ats proxy.config.cache.target_fragment_size INT 1048576 I use curl to get them : for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done very file just get once, i can see ats memory usage is 138M After i use curl to purge them : for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done I can see ats memory usage is 246M very file removed from ats, why the memory usage enlarge about 100M purge waste memory -- Key: TS-2724 URL: https://issues.apache.org/jira/browse/TS-2724 Project: Traffic Server Issue Type: Bug Reporter: bettydramit I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M records.config {code} proxy.config.cache.target_fragment_size INT 1048576 {code} I use curl to get them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done {code} every file just get once, i can see ats memory usage is 138M After use curl to purge them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done {code} I can see ats memory usage is 246M every file removed from ats, why the memory usage enlarge about 100M -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2724) purge waste memory
[ https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-2724: Affects Version/s: 4.2.0 purge waste memory -- Key: TS-2724 URL: https://issues.apache.org/jira/browse/TS-2724 Project: Traffic Server Issue Type: Bug Affects Versions: 4.2.0 Reporter: bettydramit I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M records.config {code} proxy.config.cache.target_fragment_size INT 1048576 {code} I use curl to get them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done {code} every file just get once, i can see ats memory usage is 138M After use curl to purge them : {code} for((i=0;i100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done {code} I can see ats memory usage is 246M every file removed from ats, why the memory usage enlarge about 100M -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2725) When using the transform in the plugins, the query results from traffic_line is incorrect
acache created TS-2725: -- Summary: 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: Stats Reporter: acache the results of used transform: ``` [root@ats plugins]# tsar --ts --ts_os -l Time ts-- --ts_os Time qpscons Bps rt rpc qpscons Bps rpc 17/04/14-20:22:35 4.004.00 112.8M0.001.00 4.004.00 964.001.00 17/04/14-20:22:40 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:22:45 0.000.000.000.000.00 0.000.00 0.000.00 17/04/14-20:22:50 3.803.80 107.2M0.001.00 3.803.80 915.801.00 17/04/14-20:22:55 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:23:00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 17/04/14-20:23:05 4.004.00 107.2M0.001.00 4.004.00 915.801.00 17/04/14-20:23:10 4.004.00 112.8M0.001.00 4.004.00 964.001.00 17/04/14-20:23:15 4.004.00 107.2M0.001.00 4.004.00 915.801.00 17/04/14-20:23:20 4.004.00 112.8M0.001.00 4.004.00 964.001.00 17/04/14-20:23:25 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:23:30 4.204.20 118.4M0.001.00 4.204.20 1.0K1.00 17/04/14-20:23:35 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:23:40 4.204.20 118.4M0.001.00 4.204.20 1.0K1.00 17/04/14-20:23:45 4.004.00 107.2M0.001.00 4.004.00 915.801.00 ``` without transform: ``` 17/04/14-20:24:20 25.60 25.60 716.3M 78.171.0025.60 25.60 716.3M1.00 17/04/14-20:24:25 24.60 24.60 693.7M 80.801.0024.60 24.60 693.7M1.00 17/04/14-20:24:30 25.20 25.20 705.0M 79.311.0025.20 25.20 705.0M1.00 17/04/14-20:24:35 24.80 24.80 699.4M 79.631.0024.80 24.80 699.4M1.00 17/04/14-20:24:40 25.60 25.60 716.3M 78.301.0025.60 25.60 716.3M1.00 17/04/14-20:24:45 25.00 25.00 705.0M 79.571.0025.00 25.00 705.0M1.00 17/04/14-20:24:50 25.40 25.40 710.7M 78.301.0025.40 25.40 710.7M1.00 17/04/14-20:24:55 24.80 24.80 699.4M 79.911.0024.80 24.80 699.4M1.00 17/04/14-20:25:00 25.00 25.00 699.4M 79.961.0025.00 25.00 699.4M1.00 17/04/14-20:25:05 24.60 24.60 693.7M 80.541.0024.60 24.60 693.7M1.00 17/04/14-20:25:10 25.80 25.80 721.9M 77.881.0025.80 25.80 721.9M1.00 17/04/14-20:25:15 24.80 24.80 699.4M 79.871.0024.80 24.80 699.4M1.00 17/04/14-20:25:20 24.40 24.40 682.5M 81.001.0024.40 24.40 682.5M1.00 ``` -- 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: the results of used transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts-- --ts_os qps cons Bps rt rpc qpsconsBps rpc 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 ``` without transform: ``` 25.60 25.60 716.3M 78.171.0025.60 25.60 716.3M1.00 24.60 24.60 693.7M 80.801.0024.60 24.60 693.7M1.00 25.20 25.20 705.0M 79.311.0025.20 25.20 705.0M1.00 24.80 24.80 699.4M 79.631.0024.80 24.80 699.4M1.00 25.60 25.60 716.3M 78.301.0025.60 25.60 716.3M1.00 25.00 25.00 705.0M 79.571.0025.00 25.00 705.0M1.00 25.40 25.40 710.7M 78.301.0025.40 25.40 710.7M1.00 24.80 24.80 699.4M 79.911.0024.80 24.80 699.4M1.00 25.00 25.00 699.4M 79.961.0025.00 25.00 699.4M1.00 24.60 24.60 693.7M 80.541.0024.60 24.60 693.7M1.00 25.80 25.80 721.9M 77.881.0025.80 25.80 721.9M1.00 24.80 24.80 699.4M 79.871.0024.80 24.80 699.4M1.00 24.40 24.40 682.5M 81.001.0024.40 24.40 682.5M1.00 ``` was: the results of used transform: ``` [root@ats plugins]# tsar --ts --ts_os -l Time ts-- --ts_os Time qpscons Bps rt rpc qpscons Bps rpc 17/04/14-20:22:35 4.004.00 112.8M0.001.00 4.004.00 964.001.00 17/04/14-20:22:40 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:22:45 0.000.000.000.000.00 0.000.00 0.000.00 17/04/14-20:22:50 3.803.80 107.2M0.001.00 3.803.80 915.801.00 17/04/14-20:22:55 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:23:00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 17/04/14-20:23:05 4.004.00 107.2M0.001.00 4.004.00 915.801.00 17/04/14-20:23:10 4.004.00 112.8M0.001.00 4.004.00 964.001.00 17/04/14-20:23:15 4.004.00 107.2M0.001.00 4.004.00 915.801.00 17/04/14-20:23:20 4.004.00 112.8M0.001.00 4.004.00 964.001.00 17/04/14-20:23:25 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:23:30 4.204.20 118.4M0.001.00 4.204.20 1.0K1.00 17/04/14-20:23:35 4.204.20 112.8M0.001.00 4.204.20 964.001.00 17/04/14-20:23:40 4.204.20 118.4M0.001.00 4.204.20 1.0K1.00 17/04/14-20:23:45 4.004.00 107.2M0.001.00 4.004.00 915.801.00 ``` without transform: ``` 17/04/14-20:24:20 25.60 25.60 716.3M 78.171.0025.60 25.60 716.3M1.00 17/04/14-20:24:25 24.60 24.60 693.7M 80.801.0024.60 24.60 693.7M1.00 17/04/14-20:24:30 25.20 25.20 705.0M 79.311.0025.20 25.20 705.0M1.00 17/04/14-20:24:35 24.80 24.80 699.4M 79.631.0024.80 24.80 699.4M1.00 17/04/14-20:24:40 25.60 25.60 716.3M 78.301.0025.60 25.60 716.3M1.00 17/04/14-20:24:45 25.00 25.00 705.0M 79.571.0025.00 25.00 705.0M1.00 17/04/14-20:24:50 25.40 25.40 710.7M 78.301.0025.40 25.40 710.7M1.00 17/04/14-20:24:55 24.80 24.80 699.4M 79.911.0024.80 24.80 699.4M1.00 17/04/14-20:25:00 25.00 25.00 699.4M 79.961.0025.00 25.00 699.4M1.00
[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: the results of used transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts-- --ts_os qps cons Bps rt rpc qpsconsBps rpc 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts-- --ts_os qps cons Bps rt rpc qpsconsBps rpc 25.60 25.60 716.3M 78.171.0025.60 25.60 716.3M1.00 24.60 24.60 693.7M 80.801.0024.60 24.60 693.7M1.00 25.20 25.20 705.0M 79.311.0025.20 25.20 705.0M1.00 24.80 24.80 699.4M 79.631.0024.80 24.80 699.4M1.00 25.60 25.60 716.3M 78.301.0025.60 25.60 716.3M1.00 25.00 25.00 705.0M 79.571.0025.00 25.00 705.0M1.00 25.40 25.40 710.7M 78.301.0025.40 25.40 710.7M1.00 24.80 24.80 699.4M 79.911.0024.80 24.80 699.4M1.00 25.00 25.00 699.4M 79.961.0025.00 25.00 699.4M1.00 24.60 24.60 693.7M 80.541.0024.60 24.60 693.7M1.00 25.80 25.80 721.9M 77.881.0025.80 25.80 721.9M1.00 24.80 24.80 699.4M 79.871.0024.80 24.80 699.4M1.00 24.40 24.40 682.5M 81.001.0024.40 24.40 682.5M1.00 ``` was: the results of used transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts-- --ts_os qps cons Bps rt rpc qpsconsBps rpc 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 ``` without transform: ``` 25.60 25.60 716.3M 78.171.0025.60 25.60 716.3M1.00 24.60 24.60 693.7M 80.801.0024.60 24.60 693.7M1.00 25.20 25.20 705.0M 79.311.0025.20 25.20 705.0M1.00 24.80 24.80 699.4M 79.631.0024.80 24.80 699.4M1.00 25.60 25.60 716.3M 78.301.0025.60 25.60 716.3M1.00 25.00 25.00 705.0M 79.571.0025.00 25.00 705.0M1.00 25.40 25.40 710.7M 78.301.0025.40 25.40 710.7M1.00 24.80 24.80 699.4M 79.911.0024.80 24.80 699.4M1.00 25.00 25.00 699.4M 79.961.0025.00 25.00 699.4M1.00 24.60 24.60 693.7M 80.541.0024.60 24.60 693.7M1.00 25.80 25.80 721.9M 77.881.0025.80 25.80 721.9M1.00 24.80 24.80 699.4M 79.871.0024.80 24.80 699.4M1.00 24.40 24.40 682.5M 81.001.0024.40 24.40 682.5M1.00 ``` When using the transform in the plugins, the query results from traffic_line is incorrect
[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: the results of used transform: [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: the results of used transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts-- --ts_os qps cons Bps rt rpc qpsconsBps rpc 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 3.803.80 107.2M0.001.00 3.803.80 915.801.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 4.004.00 112.8M0.001.00 4.004.00 964.001.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.204.20 112.8M0.001.00 4.204.20 964.001.00 4.204.20 118.4M0.001.00 4.204.201.0K1.00 4.004.00 107.2M0.001.00 4.004.00 915.801.00 ``` without transform: ``` [root@ats plugins]# tsar --ts --ts_os -l ts-- --ts_os qps cons Bps rt rpc qpsconsBps rpc 25.60 25.60 716.3M 78.171.0025.60 25.60 716.3M1.00 24.60 24.60 693.7M 80.801.0024.60 24.60 693.7M1.00 25.20 25.20 705.0M 79.311.0025.20 25.20 705.0M1.00 24.80 24.80 699.4M 79.631.0024.80 24.80 699.4M1.00 25.60 25.60 716.3M 78.301.0025.60 25.60 716.3M1.00 25.00 25.00 705.0M 79.571.0025.00 25.00 705.0M1.00 25.40 25.40 710.7M 78.301.0025.40 25.40 710.7M1.00 24.80 24.80 699.4M 79.911.0024.80 24.80 699.4M1.00 25.00 25.00 699.4M 79.961.0025.00 25.00 699.4M1.00 24.60 24.60 693.7M 80.541.0024.60 24.60 693.7M1.00 25.80 25.80 721.9M 77.881.0025.80 25.80 721.9M1.00 24.80 24.80 699.4M 79.871.0024.80 24.80 699.4M1.00 24.40 24.40 682.5M 81.001.0024.40 24.40 682.5M1.00 ``` 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: Stats Affects Versions: 4.2.0 Environment: centos6 Reporter: acache the results of used transform: [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-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: origin server:127.0.0.1:80(nginx),ats(4.2.0) no-cache the results of used transform: [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: the results of used transform: [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: Stats Affects Versions: 4.2.0 Environment: centos6 Reporter: acache origin server:127.0.0.1:80(nginx),ats(4.2.0) no-cache the results of used transform: [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-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: test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M the results of used transform: [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: origin server:127.0.0.1:80(nginx),ats(4.2.0) no-cache the results of used transform: [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: Stats Affects Versions: 4.2.0 Environment: centos6 Reporter: acache test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M the results of used transform: [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-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: test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M the results of used transform(used 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: test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M the results of used transform: [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: Stats Affects Versions: 4.2.0 Environment: centos6 Reporter: acache test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M the results of used transform(used 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-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: 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 with traffic_line. the results of used transform(used 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: test : origin server:127.0.0.1:80(nginx); ats(4.2.0) never-cache; qps:25 request file: 25M the results of used transform(used 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: Stats Affects Versions: 4.2.0 Environment: centos6 Reporter: acache 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 with traffic_line. the results of used transform(used 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] [Commented] (TS-2720) atscppapi: Request transformation doesn't work in streaming mode
[ https://issues.apache.org/jira/browse/TS-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973137#comment-13973137 ] ASF subversion and git services commented on TS-2720: - Commit a4860363a94e7bb51e5de651c5ea07a804915777 in trafficserver's branch refs/heads/5.0.x from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a486036 ] [TS-2720] Fixing bug in C++ API Request Transformations atscppapi: Request transformation doesn't work in streaming mode Key: TS-2720 URL: https://issues.apache.org/jira/browse/TS-2720 Project: Traffic Server Issue Type: Bug Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 5.0.0 When a request xform produces data before input has been consumed, the core is throwing a no content length error and ends up crashing the process. The crash is a separate issue, but the api should handle streaming situation correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2704) Core dump in state_raw_http_server_open
[ https://issues.apache.org/jira/browse/TS-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973260#comment-13973260 ] ASF subversion and git services commented on TS-2704: - Commit 109a92ac1ca5db93f36b7657671a42817ac553fd in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=109a92a ] TS-2704: Core dump in state_raw_http_server_open getting EVENT_INTERVAL event Core dump in state_raw_http_server_open --- Key: TS-2704 URL: https://issues.apache.org/jira/browse/TS-2704 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2704.diff During production roll out of one of our properties, we observed ATS crashing with the below backtrace. Upon some investigation, we found that EVENT_INTERVAL was somehow unexpectedly being delivered to state_raw_http_server_open and is falling into the default handler resulting in a crash. While we are continuing to understand how the unexpected EVENT_INTERVAL ended up in state_raw_http_server, this protection fix was added to ignore the unexpected event. #0 0x003021a328e5 in raise () from /lib64/libc.so.6 #1 0x003021a340c5 in abort () from /lib64/libc.so.6 #2 0x2b1ef4b9fcd9 in ink_die_die_die (retval=4878) at ink_error.cc:43 #3 0x2b1ef4b9ff03 in ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *) (return_code=1, message_format=value optimized out, ap=0x2b1ef7fdbbb0) at ink_error.cc:65 #4 0x2b1ef4ba0038 in ink_fatal (return_code=4878, message_format=0x1313 Address 0x1313 out of bounds) at ink_error.cc:73 #5 0x2b1ef4b9e51f in _ink_assert (expression=0x0, file=0x6 Address 0x6 out of bounds, line=-1) at ink_assert.cc:37 #6 0x005206ef in HttpSM::state_raw_http_server_open (this=0x2b1f19fbeeb0, event=2, data=0x2b1fa00066b0) at HttpSM.cc:1135 #7 0x005342d8 in HttpSM::main_handler (this=0x2b1f19fbeeb0, event=2, data=0x2b1fa00066b0) at HttpSM.cc:2516 #8 0x006a6c8f in handleEvent (this=0x2b1ef67c5010, e=0x2b1fa00066b0, calling_code=2) at I_Continuation.h:146 #9 EThread::process_event (this=0x2b1ef67c5010, e=0x2b1fa00066b0, calling_code=2) at UnixEThread.cc:141 #10 0x006a7853 in EThread::execute (this=0x2b1ef67c5010) at UnixEThread.cc:220 #11 0x006a5b2a in spawn_thread_internal (a=0x1804b80) at Thread.cc:88 #12 0x2b1ef5357851 in start_thread () from /lib64/libpthread.so.0 #13 0x003021ae894d in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2710) ATS serves the wrong cert because it matches wildcard certs incorrectly
[ https://issues.apache.org/jira/browse/TS-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2710: -- Assignee: Bryan Call ATS serves the wrong cert because it matches wildcard certs incorrectly --- Key: TS-2710 URL: https://issues.apache.org/jira/browse/TS-2710 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 5.0.0 Reporter: manish thakrani Assignee: Bryan Call Labels: yahoo Fix For: 5.0.0 Attachments: ts2710.diff If one cert available has a SAN entry for *.a.b.com and another has a SAN entry for *.b.com, a request for a.b.com will be given the SAN with the *.a.b.com SAN entry, which will cause the browser to show the cert does not match error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2700) Unclear balancer plugin documentation
[ https://issues.apache.org/jira/browse/TS-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibault Marquand updated TS-2700: -- Priority: Minor (was: Major) Issue Type: Improvement (was: Bug) Summary: Unclear balancer plugin documentation (was: No TSPluginInit ) Unclear balancer plugin documentation - Key: TS-2700 URL: https://issues.apache.org/jira/browse/TS-2700 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Thibault Marquand Priority: Minor Documentation indicates that plugins must have a TSPluginInit function and there is not one in balancer plugin. Did I miss something ? I am going to try to write one but I am newer with trafficserver. Edit : I write a TSPluginInit function from this example [http://trafficserver.readthedocs.org/en/latest/reference/api/TSHttpHookAdd.en.html] Now, trafficserver can load balancer plugin but it still doesn't work. From /var/log/trafficserver/traffic.out : {quote} FATAL: unable to load 'X~�G+': [Apr 4 /bin/traffic_server - STACK TRACE: //lib/libtsutil.so.4(+0x10e84)[0x2b47ce7cfe84] /bin/traffic_server(_ZNK5Diags5errorE10DiagsLevelPKcS2_iS2_z+0x7a)[0x49bb6a] /bin/traffic_server(_Z11plugin_initv+0x64e)[0x4dd9fe] /bin/traffic_server(main+0xe84)[0x495574] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x2b47d0e27ead] /bin/traffic_server[0x499a2d] {quote} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2726) Weighted scheduler algorithm for balancer plugin
Thibault Marquand created TS-2726: - Summary: 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 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-2726) Weighted scheduler algorithm for balancer plugin
[ https://issues.apache.org/jira/browse/TS-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibault Marquand updated TS-2726: -- Priority: Minor (was: Major) 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 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] [Commented] (TS-2726) Weighted scheduler algorithm for balancer plugin
[ https://issues.apache.org/jira/browse/TS-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973339#comment-13973339 ] James Peach commented on TS-2726: - The balancer plugin balances requests, not sessions or connections. It would be interesting to have a policy that favors highest weight or lowest response time. The latter might be preferable since it is a bit more auto-tuning, though tracking the status is more complex. 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 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] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973477#comment-13973477 ] Bryan Call commented on TS-1125: Talked to Sudheer and we agreed that the code in VC_EVENT_WRITE_COMPLETE isn't needed with the way the 100-continue is now implemented. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2548) Add client IP to SSLError() calls in SSLNetVConnection
[ https://issues.apache.org/jira/browse/TS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973496#comment-13973496 ] ASF subversion and git services commented on TS-2548: - Commit 700875f18db67df6e2a530a74d5f1ac4f6814d6d in trafficserver's branch refs/heads/master from [~Kang Li] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=700875f ] TS-2548: Add client IP to SSLError() calls in SSLNetVConnection Add client IP to SSLError() calls in SSLNetVConnection --- Key: TS-2548 URL: https://issues.apache.org/jira/browse/TS-2548 Project: Traffic Server Issue Type: Improvement Components: Logging, SSL Reporter: David Carlin Labels: review, yahoo Fix For: 5.0.0 Attachments: ssl_log_enhancement.diff I asked on IRC if we could put the Client IP in the SSL errors that appear in diags.log and /var/log/messages - jpeach replied that it was a matter of adding client IP to SSLError() calls in SSLNetVConnection. This would be very helpful for troubleshooting. Additionally, why are the errors sent to /var/log/messages - writing them to only diags.log is preferable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2548) Add client IP to SSLError() calls in SSLNetVConnection
[ https://issues.apache.org/jira/browse/TS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973499#comment-13973499 ] Bryan Call commented on TS-2548: I updated the patch to not make a copy of the sockaddr before converting the ip to a string. Also, I changed the flag to a bool instead of an int. Add client IP to SSLError() calls in SSLNetVConnection --- Key: TS-2548 URL: https://issues.apache.org/jira/browse/TS-2548 Project: Traffic Server Issue Type: Improvement Components: Logging, SSL Reporter: David Carlin Labels: review, yahoo Fix For: 5.0.0 Attachments: ssl_log_enhancement.diff I asked on IRC if we could put the Client IP in the SSL errors that appear in diags.log and /var/log/messages - jpeach replied that it was a matter of adding client IP to SSLError() calls in SSLNetVConnection. This would be very helpful for troubleshooting. Additionally, why are the errors sent to /var/log/messages - writing them to only diags.log is preferable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-1125: -- Assignee: Bryan Call POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2548) Add client IP to SSLError() calls in SSLNetVConnection
[ https://issues.apache.org/jira/browse/TS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2548: -- Assignee: Bryan Call Add client IP to SSLError() calls in SSLNetVConnection --- Key: TS-2548 URL: https://issues.apache.org/jira/browse/TS-2548 Project: Traffic Server Issue Type: Improvement Components: Logging, SSL Reporter: David Carlin Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ssl_log_enhancement.diff I asked on IRC if we could put the Client IP in the SSL errors that appear in diags.log and /var/log/messages - jpeach replied that it was a matter of adding client IP to SSLError() calls in SSLNetVConnection. This would be very helpful for troubleshooting. Additionally, why are the errors sent to /var/log/messages - writing them to only diags.log is preferable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TS-2624) CPU affinity assumes linear mapping
[ https://issues.apache.org/jira/browse/TS-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reopened TS-2624: --- Backport to Version: 4.2.1 I'd like to back port the following piece to 4.2.x: {code} diff --git a/mgmt/Makefile.am b/mgmt/Makefile.am index db485c8..b1a3e33 100644 --- a/mgmt/Makefile.am +++ b/mgmt/Makefile.am @@ -104,7 +104,7 @@ traffic_manager_LDADD = \ $(top_builddir)/iocore/eventsystem/libinkevent.a \ $(top_builddir)/proxy/shared/liberror.a \ $(top_builddir)/proxy/shared/libdiagsconfig.a \ - @LIBRESOLV@ @LIBEXPAT@ @LIBPCRE@ @LIBTCL@ @LIBCAP@ \ + @LIBRESOLV@ @LIBEXPAT@ @LIBPCRE@ @LIBTCL@ @LIBCAP@ @hwloc_LIBS@ \ -lm # Must do it this way or the dependencies aren't detected. {code} CPU affinity assumes linear mapping --- Key: TS-2624 URL: https://issues.apache.org/jira/browse/TS-2624 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.0.0 The current CPU affinity code assumes that Core/PU mappings are linear, when they can also be interleaved. We should consult HWLOC and use some of the other convenience functions there to properly map threads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2727) hwloc_CFLAGS gets odd values
[ https://issues.apache.org/jira/browse/TS-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2727: - Assignee: Leif Hedstrom hwloc_CFLAGS gets odd values Key: TS-2727 URL: https://issues.apache.org/jira/browse/TS-2727 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 I'm not sure exactly what the intent is, but we set hwloc_CFLAGS, and as far as I can tell, we don't set it. This has some weird side effects, such as config.log showing: {code} hwloc_CFLAGS='-I/usr/include/libxml2 ' {code} which obviously doesn't seem to make any sense. I suggest we just eliminate the hwloc_CFLAGS now, until we actually use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2727) hwloc_CFLAGS gets odd values
Leif Hedstrom created TS-2727: - Summary: hwloc_CFLAGS gets odd values Key: TS-2727 URL: https://issues.apache.org/jira/browse/TS-2727 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom I'm not sure exactly what the intent is, but we set hwloc_CFLAGS, and as far as I can tell, we don't set it. This has some weird side effects, such as config.log showing: {code} hwloc_CFLAGS='-I/usr/include/libxml2 ' {code} which obviously doesn't seem to make any sense. I suggest we just eliminate the hwloc_CFLAGS now, until we actually use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2728) the lib/perl Makefile.am does not properly detect out-of-source builds
[ https://issues.apache.org/jira/browse/TS-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2728: -- Fix Version/s: 5.0.0 the lib/perl Makefile.am does not properly detect out-of-source builds -- Key: TS-2728 URL: https://issues.apache.org/jira/browse/TS-2728 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 It seems that the out-of-source builds for our Perl modules is somewhat confused. I think the tests are not correct, such that we try to cp the source tree even when we're doing an in-source build (which then makes cp complain that source and destination is the same). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2728) the lib/perl Makefile.am does not properly detect out-of-source builds
[ https://issues.apache.org/jira/browse/TS-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2728: - Assignee: Leif Hedstrom the lib/perl Makefile.am does not properly detect out-of-source builds -- Key: TS-2728 URL: https://issues.apache.org/jira/browse/TS-2728 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 It seems that the out-of-source builds for our Perl modules is somewhat confused. I think the tests are not correct, such that we try to cp the source tree even when we're doing an in-source build (which then makes cp complain that source and destination is the same). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2728) the lib/perl Makefile.am does not properly detect out-of-source builds
Leif Hedstrom created TS-2728: - Summary: the lib/perl Makefile.am does not properly detect out-of-source builds Key: TS-2728 URL: https://issues.apache.org/jira/browse/TS-2728 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom It seems that the out-of-source builds for our Perl modules is somewhat confused. I think the tests are not correct, such that we try to cp the source tree even when we're doing an in-source build (which then makes cp complain that source and destination is the same). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: ts2650.diff Updated the patch per Bryan's comments: 1. remove a unnecessary null terminations. 2. Added a few more similar 3xx redirect response codes that return Location header Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973551#comment-13973551 ] ASF subversion and git services commented on TS-1125: - Commit 9da123014382c00bccb1869782a4f2502229a459 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9da1230 ] TS-1125: POST's with Expect: 100-continue are slowed by delayed 100 response Additional Authors: Feifei Cai ff...@yahoo-inc.com Sudheer Vinukonda sudhe...@yahoo-inc.com POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2650: -- Attachment: ts2650.diff fixed the path of the patch files Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2720) atscppapi: Request transformation doesn't work in streaming mode
[ https://issues.apache.org/jira/browse/TS-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973575#comment-13973575 ] ASF GitHub Bot commented on TS-2720: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/73 atscppapi: Request transformation doesn't work in streaming mode Key: TS-2720 URL: https://issues.apache.org/jira/browse/TS-2720 Project: Traffic Server Issue Type: Bug Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 5.0.0 When a request xform produces data before input has been consumed, the core is throwing a no content length error and ends up crashing the process. The crash is a separate issue, but the api should handle streaming situation correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973583#comment-13973583 ] ASF subversion and git services commented on TS-2650: - Commit 56fbfdd292e7e94a30bb596a11a2f2db4d56c52f in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=56fbfdd ] TS-2650: Redirect handling enhancements in ATS Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2548) Add client IP to SSLError() calls in SSLNetVConnection
[ https://issues.apache.org/jira/browse/TS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973591#comment-13973591 ] ASF subversion and git services commented on TS-2548: - Commit bdcf937732aaa2004640bd4fc6fb3e20cc4ec008 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bdcf937 ] Added TS-2650, TS-1125, TS-2548, TS-2710, TS-2704 to CHANGES Add client IP to SSLError() calls in SSLNetVConnection --- Key: TS-2548 URL: https://issues.apache.org/jira/browse/TS-2548 Project: Traffic Server Issue Type: Improvement Components: Logging, SSL Reporter: David Carlin Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ssl_log_enhancement.diff I asked on IRC if we could put the Client IP in the SSL errors that appear in diags.log and /var/log/messages - jpeach replied that it was a matter of adding client IP to SSLError() calls in SSLNetVConnection. This would be very helpful for troubleshooting. Additionally, why are the errors sent to /var/log/messages - writing them to only diags.log is preferable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973589#comment-13973589 ] ASF subversion and git services commented on TS-2650: - Commit bdcf937732aaa2004640bd4fc6fb3e20cc4ec008 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bdcf937 ] Added TS-2650, TS-1125, TS-2548, TS-2710, TS-2704 to CHANGES Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2710) ATS serves the wrong cert because it matches wildcard certs incorrectly
[ https://issues.apache.org/jira/browse/TS-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973592#comment-13973592 ] ASF subversion and git services commented on TS-2710: - Commit bdcf937732aaa2004640bd4fc6fb3e20cc4ec008 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bdcf937 ] Added TS-2650, TS-1125, TS-2548, TS-2710, TS-2704 to CHANGES ATS serves the wrong cert because it matches wildcard certs incorrectly --- Key: TS-2710 URL: https://issues.apache.org/jira/browse/TS-2710 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 5.0.0 Reporter: manish thakrani Assignee: Bryan Call Labels: yahoo Fix For: 5.0.0 Attachments: ts2710.diff If one cert available has a SAN entry for *.a.b.com and another has a SAN entry for *.b.com, a request for a.b.com will be given the SAN with the *.a.b.com SAN entry, which will cause the browser to show the cert does not match error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2704) Core dump in state_raw_http_server_open
[ https://issues.apache.org/jira/browse/TS-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973593#comment-13973593 ] ASF subversion and git services commented on TS-2704: - Commit bdcf937732aaa2004640bd4fc6fb3e20cc4ec008 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bdcf937 ] Added TS-2650, TS-1125, TS-2548, TS-2710, TS-2704 to CHANGES Core dump in state_raw_http_server_open --- Key: TS-2704 URL: https://issues.apache.org/jira/browse/TS-2704 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2704.diff During production roll out of one of our properties, we observed ATS crashing with the below backtrace. Upon some investigation, we found that EVENT_INTERVAL was somehow unexpectedly being delivered to state_raw_http_server_open and is falling into the default handler resulting in a crash. While we are continuing to understand how the unexpected EVENT_INTERVAL ended up in state_raw_http_server, this protection fix was added to ignore the unexpected event. #0 0x003021a328e5 in raise () from /lib64/libc.so.6 #1 0x003021a340c5 in abort () from /lib64/libc.so.6 #2 0x2b1ef4b9fcd9 in ink_die_die_die (retval=4878) at ink_error.cc:43 #3 0x2b1ef4b9ff03 in ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *) (return_code=1, message_format=value optimized out, ap=0x2b1ef7fdbbb0) at ink_error.cc:65 #4 0x2b1ef4ba0038 in ink_fatal (return_code=4878, message_format=0x1313 Address 0x1313 out of bounds) at ink_error.cc:73 #5 0x2b1ef4b9e51f in _ink_assert (expression=0x0, file=0x6 Address 0x6 out of bounds, line=-1) at ink_assert.cc:37 #6 0x005206ef in HttpSM::state_raw_http_server_open (this=0x2b1f19fbeeb0, event=2, data=0x2b1fa00066b0) at HttpSM.cc:1135 #7 0x005342d8 in HttpSM::main_handler (this=0x2b1f19fbeeb0, event=2, data=0x2b1fa00066b0) at HttpSM.cc:2516 #8 0x006a6c8f in handleEvent (this=0x2b1ef67c5010, e=0x2b1fa00066b0, calling_code=2) at I_Continuation.h:146 #9 EThread::process_event (this=0x2b1ef67c5010, e=0x2b1fa00066b0, calling_code=2) at UnixEThread.cc:141 #10 0x006a7853 in EThread::execute (this=0x2b1ef67c5010) at UnixEThread.cc:220 #11 0x006a5b2a in spawn_thread_internal (a=0x1804b80) at Thread.cc:88 #12 0x2b1ef5357851 in start_thread () from /lib64/libpthread.so.0 #13 0x003021ae894d in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973590#comment-13973590 ] ASF subversion and git services commented on TS-1125: - Commit bdcf937732aaa2004640bd4fc6fb3e20cc4ec008 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bdcf937 ] Added TS-2650, TS-1125, TS-2548, TS-2710, TS-2704 to CHANGES POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2728) the lib/perl Makefile.am does not properly detect out-of-source builds
[ https://issues.apache.org/jira/browse/TS-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973763#comment-13973763 ] James Peach commented on TS-2728: - All the jenkins builds are out of tree, as well as {{ci/regression}} builds. So out of tree doesn't seem like it's broken in all cases. The only case that I'm aware of is that Makefile.PL in generated to be system-specific, so if you do a build, the resulting source tree cannot be used with a different system unless there is an intervening {{make distclean}}. the lib/perl Makefile.am does not properly detect out-of-source builds -- Key: TS-2728 URL: https://issues.apache.org/jira/browse/TS-2728 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 It seems that the out-of-source builds for our Perl modules is somewhat confused. I think the tests are not correct, such that we try to cp the source tree even when we're doing an in-source build (which then makes cp complain that source and destination is the same). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reopened TS-1125: - This change crashes {{traffic_manager}} and {{traffic_server}} on startup every time. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2728) the lib/perl Makefile.am does not properly detect out-of-source builds
[ https://issues.apache.org/jira/browse/TS-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973788#comment-13973788 ] Leif Hedstrom commented on TS-2728: --- Yeah, I got it wrong, I think it's the in-source builds that are broken (at least from what Igor showed me). I'll look more tomorrow. the lib/perl Makefile.am does not properly detect out-of-source builds -- Key: TS-2728 URL: https://issues.apache.org/jira/browse/TS-2728 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 It seems that the out-of-source builds for our Perl modules is somewhat confused. I think the tests are not correct, such that we try to cp the source tree even when we're doing an in-source build (which then makes cp complain that source and destination is the same). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2654) Range request crash in trafficserver 4.2.0
[ https://issues.apache.org/jira/browse/TS-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973800#comment-13973800 ] bettydramit commented on TS-2654: - [~zwoop] git master will be crash {code} c++filt a.txt NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf70f)[0x2b7534cd370f] /usr/bin/traffic_server(HTTPInfo::object_size_get()+0x17)[0x506a67] /usr/bin/traffic_server(HttpTransact::change_response_header_because_of_range_request(HttpTransact::State*, HTTPHdr*)+0x209)[0x5a3d0b] /usr/bin/traffic_server(HttpTransact::handle_content_length_header(HttpTransact::State*, HTTPHdr*, HTTPHdr*)+0x1e3)[0x59c3c3] /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*, HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x18b)[0x5a0c67] /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*, HTTPHdr*, HTTPHdr*, HTTPVersion)+0x3d)[0x5a0a8b] /usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)+0x1b0)[0x595452] /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void (*)(HttpTransact::State*))+0x83)[0x577575] /usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int, void*)+0x1a0)[0x565842] /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x23c)[0x5698ca] /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e9a07] /usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)+0x2de)[0x52ea8a] /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e9a07] /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xc7)[0x6e2867] /usr/bin/traffic_server(EThread::execute()+0x9f)[0x6e2a35] /usr/bin/traffic_server(main+0x123a)[0x512944] /lib64/libc.so.6(__libc_start_main+0xfc)[0x2b7535bf7d1c] /usr/bin/traffic_server[0x4cc8c8] {code} Range request crash in trafficserver 4.2.0 -- Key: TS-2654 URL: https://issues.apache.org/jira/browse/TS-2654 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Chaokovsky Lee Assignee: Leif Hedstrom Priority: Critical Labels: crash Fix For: 4.2.1, 5.0.0 I have updated trafficserver from 4.1.2 to 4.2.0, but the range request crash bug even appear. I use read while writer feature in my configuration, Maybe the feature cause crash ? CONFIG proxy.config.cache.enable_read_while_writer INT 1 {code} /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x3a8300f4a0] /usr/bin/traffic_server(HttpTransact::change_response_header_because_of_range_request(HttpTransact::State*, HTTPHdr*)+0x255)[0x533295] /usr/bin/traffic_server(HttpTransact::handle_content_length_header(HttpTransact::State*, HTTPHdr*, HTTPHdr*)+0x2c8)[0x533638] /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*, HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x460)[0x533b40] /usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)+0x7d)[0x53a2dd] /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void (*)(HttpTransact::State*))+0x28)[0x50b268] /usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int, void*)+0xed)[0x514b4d] /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x70)[0x51feb0] /usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)+0x1d6)[0x4df8d6] /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x66d37f] /usr/bin/traffic_server(EThread::execute()+0x61b)[0x66deab] /usr/bin/traffic_server[0x66c89a] /lib64/libpthread.so.0[0x3a830077f1] /lib64/libc.so.6(clone+0x6d)[0x3a82ce570d] {code} Thank for your excellent work, the trafficserver is so great! -- This message was sent by Atlassian JIRA (v6.2#6252)