[jira] [Created] (TS-2724) purge waste memory

2014-04-17 Thread bettydramit (JIRA)
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

2014-04-17 Thread bettydramit (JIRA)

 [ 
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

2014-04-17 Thread bettydramit (JIRA)

 [ 
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

2014-04-17 Thread bettydramit (JIRA)

 [ 
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

2014-04-17 Thread acache (JIRA)
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

2014-04-17 Thread acache (JIRA)

 [ 
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

2014-04-17 Thread acache (JIRA)

 [ 
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

2014-04-17 Thread acache (JIRA)

 [ 
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

2014-04-17 Thread acache (JIRA)

 [ 
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

2014-04-17 Thread acache (JIRA)

 [ 
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

2014-04-17 Thread acache (JIRA)

 [ 
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

2014-04-17 Thread acache (JIRA)

 [ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread Bryan Call (JIRA)

 [ 
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

2014-04-17 Thread Thibault Marquand (JIRA)

 [ 
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

2014-04-17 Thread Thibault Marquand (JIRA)
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

2014-04-17 Thread Thibault Marquand (JIRA)

 [ 
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

2014-04-17 Thread James Peach (JIRA)

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

2014-04-17 Thread Bryan Call (JIRA)

[ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread Bryan Call (JIRA)

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

2014-04-17 Thread Bryan Call (JIRA)

 [ 
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

2014-04-17 Thread Bryan Call (JIRA)

 [ 
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

2014-04-17 Thread Leif Hedstrom (JIRA)

 [ 
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

2014-04-17 Thread Leif Hedstrom (JIRA)

 [ 
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

2014-04-17 Thread Leif Hedstrom (JIRA)
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

2014-04-17 Thread Leif Hedstrom (JIRA)

 [ 
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

2014-04-17 Thread Leif Hedstrom (JIRA)

 [ 
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

2014-04-17 Thread Leif Hedstrom (JIRA)
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

2014-04-17 Thread Sudheer Vinukonda (JIRA)

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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread Sudheer Vinukonda (JIRA)

 [ 
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

2014-04-17 Thread ASF GitHub Bot (JIRA)

[ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread ASF subversion and git services (JIRA)

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

2014-04-17 Thread ASF subversion and git services (JIRA)

[ 
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

2014-04-17 Thread James Peach (JIRA)

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

2014-04-17 Thread James Peach (JIRA)

 [ 
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

2014-04-17 Thread Leif Hedstrom (JIRA)

[ 
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

2014-04-17 Thread bettydramit (JIRA)

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