date:20161107

[jira] [Work logged] (TS-5045) Add ws and wss scheme constants.

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5045?focusedWorklogId=31766=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31766
 ]

ASF GitHub Bot logged work on TS-5045:
--

Author: ASF GitHub Bot
Created on: 08/Nov/16 05:54
Start Date: 08/Nov/16 05:54
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1211
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1086/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 31766)
Time Spent: 0.5h  (was: 20m)

> Add ws and wss scheme constants.
> 
>
> Key: TS-5045
> URL: https://issues.apache.org/jira/browse/TS-5045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We have well known strings for "ws" and "wss" schemes, but no TS API 
> constants. Let's add these for completeness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1211: TS-5045: Add ws and wss scheme constants.

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1211
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1086/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-5045) Add ws and wss scheme constants.

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5045?focusedWorklogId=31765=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31765
 ]

ASF GitHub Bot logged work on TS-5045:
--

Author: ASF GitHub Bot
Created on: 08/Nov/16 05:53
Start Date: 08/Nov/16 05:53
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1211
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1193/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 31765)
Time Spent: 20m  (was: 10m)

> Add ws and wss scheme constants.
> 
>
> Key: TS-5045
> URL: https://issues.apache.org/jira/browse/TS-5045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have well known strings for "ws" and "wss" schemes, but no TS API 
> constants. Let's add these for completeness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1211: TS-5045: Add ws and wss scheme constants.

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1211
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1193/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-5045) Add ws and wss scheme constants.

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5045?focusedWorklogId=31764=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31764
 ]

ASF GitHub Bot logged work on TS-5045:
--

Author: ASF GitHub Bot
Created on: 08/Nov/16 05:40
Start Date: 08/Nov/16 05:40
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

https://github.com/apache/trafficserver/pull/1211

TS-5045: Add ws and wss scheme constants.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jpeach/trafficserver fix/5045

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1211.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1211


commit ffef73252f202ca380bc747fd4811d087fcec052
Author: James Peach 
Date:   2016-11-08T05:39:16Z

TS-5045: Add ws and wss scheme constants.




Issue Time Tracking
---

Worklog Id: (was: 31764)
Time Spent: 10m
Remaining Estimate: 0h

> Add ws and wss scheme constants.
> 
>
> Key: TS-5045
> URL: https://issues.apache.org/jira/browse/TS-5045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have well known strings for "ws" and "wss" schemes, but no TS API 
> constants. Let's add these for completeness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1211: TS-5045: Add ws and wss scheme constants.

2016-11-07 Thread jpeach

GitHub user jpeach opened a pull request:

https://github.com/apache/trafficserver/pull/1211

TS-5045: Add ws and wss scheme constants.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jpeach/trafficserver fix/5045

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1211.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1211


commit ffef73252f202ca380bc747fd4811d087fcec052
Author: James Peach 
Date:   2016-11-08T05:39:16Z

TS-5045: Add ws and wss scheme constants.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (TS-5045) Add ws and wss scheme constants.

2016-11-07 Thread James Peach (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach reassigned TS-5045:
---

Assignee: James Peach

> Add ws and wss scheme constants.
> 
>
> Key: TS-5045
> URL: https://issues.apache.org/jira/browse/TS-5045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
>
> We have well known strings for "ws" and "wss" schemes, but no TS API 
> constants. Let's add these for completeness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-5045) Add ws and wss scheme constants.

2016-11-07 Thread James Peach (JIRA)

James Peach created TS-5045:
---

 Summary: Add ws and wss scheme constants.
 Key: TS-5045
 URL: https://issues.apache.org/jira/browse/TS-5045
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: James Peach


We have well known strings for "ws" and "wss" schemes, but no TS API constants. 
Let's add these for completeness.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-1257) Replace Tcl_Hash* with lib/ts/Map

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-1257?focusedWorklogId=31763=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31763
 ]

ASF GitHub Bot logged work on TS-1257:
--

Author: ASF GitHub Bot
Created on: 08/Nov/16 05:37
Start Date: 08/Nov/16 05:37
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1197
  
Please reformat the PR and commit subject to the convention:
```
TS-1257: Replace TCL hash table with unordered_map.
```


Issue Time Tracking
---

Worklog Id: (was: 31763)
Time Spent: 20m  (was: 10m)

> Replace Tcl_Hash* with lib/ts/Map
> -
>
> Key: TS-1257
> URL: https://issues.apache.org/jira/browse/TS-1257
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: Igor Galić
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have our own implementation of maps that we use in most new code. We have 
> already discussed looking into removing the old Tcl cruft by replacing it 
> with {{Map}}, but have neither followed up on the ML nor Jira - or in the 
> code ;)
> This ticket is a reminder that this task exists and wants to be done!
> As to whether we simply replace the Tcl Implementation underneath, or visibly 
> to all developers, replace {{InkHashTable}} with {{Map}}, remains to be 
> discussed/decided/evaluated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1197: TS-1257_ssl_cipher_name_table: replace TCL_HashTa...

2016-11-07 Thread jpeach

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1197
  
Please reformat the PR and commit subject to the convention:
```
TS-1257: Replace TCL hash table with unordered_map.
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-5040) Forward CONNECT methods without parent proxying.

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5040?focusedWorklogId=31762=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31762
 ]

ASF GitHub Bot logged work on TS-5040:
--

Author: ASF GitHub Bot
Created on: 08/Nov/16 04:25
Start Date: 08/Nov/16 04:25
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1192/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 31762)
Time Spent: 1h 20m  (was: 1h 10m)

> Forward CONNECT methods without parent proxying.
> 
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the 
> normal remap path cannot. Bring this capability to the remap state machine so 
> that plugins can do the same thing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1202: TS-5040: Forward CONNECT without parent proxying.

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1192/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-5040) Forward CONNECT methods without parent proxying.

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5040?focusedWorklogId=31761=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31761
 ]

ASF GitHub Bot logged work on TS-5040:
--

Author: ASF GitHub Bot
Created on: 08/Nov/16 04:23
Start Date: 08/Nov/16 04:23
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1085/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 31761)
Time Spent: 1h 10m  (was: 1h)

> Forward CONNECT methods without parent proxying.
> 
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the 
> normal remap path cannot. Bring this capability to the remap state machine so 
> that plugins can do the same thing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1202: TS-5040: Forward CONNECT without parent proxying.

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1085/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-5040) Forward CONNECT methods without parent proxying.

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5040?focusedWorklogId=31760=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31760
 ]

ASF GitHub Bot logged work on TS-5040:
--

Author: ASF GitHub Bot
Created on: 08/Nov/16 04:13
Start Date: 08/Nov/16 04:13
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
@zwoop Added docs.


Issue Time Tracking
---

Worklog Id: (was: 31760)
Time Spent: 1h  (was: 50m)

> Forward CONNECT methods without parent proxying.
> 
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the 
> normal remap path cannot. Bring this capability to the remap state machine so 
> that plugins can do the same thing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-5040) Forward CONNECT methods without parent proxying.

2016-11-07 Thread James Peach (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach reassigned TS-5040:
---

Assignee: James Peach

> Forward CONNECT methods without parent proxying.
> 
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the 
> normal remap path cannot. Bring this capability to the remap state machine so 
> that plugins can do the same thing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1202: TS-5040: Forward CONNECT without parent proxying.

2016-11-07 Thread jpeach

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
@zwoop Added docs.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1175: socks.config - dest_ip rule issue

2016-11-07 Thread oknet

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/issues/1175
  
yes, the v6.2.1 will be released recently.

2016-11-07 21:53 GMT+08:00 Christian Haynes :

> @oknet  Very cool, will 6.2.1 be added as a
> release and propagated through the master sites?
>
> â
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-5027) Replace readdir_r with readdir

2016-11-07 Thread Bryan Call (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-5027:
---
Summary: Replace readdir_r with readdir  (was: Replace readdir_r with 
readdir.)

> Replace readdir_r with readdir
> --
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man 
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc  -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult 
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*, 
> dirent**)' is deprecated [-Werror=deprecated-declarations]
>   while (readdir_r(dir, dirEntrySpace, ) == 0) {
>  ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-5027) Replace readdir_r with readdir.

2016-11-07 Thread Bryan Call (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-5027:
---
Backport to Version: 7.0.1

> Replace readdir_r with readdir.
> ---
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man 
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc  -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult 
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*, 
> dirent**)' is deprecated [-Werror=deprecated-declarations]
>   while (readdir_r(dir, dirEntrySpace, ) == 0) {
>  ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is back to normal : ubuntu_16_10-master » clang,ubuntu_16_10,release #13

2016-11-07 Thread jenkins

https://ci.trafficserver.apache.org/job/ubuntu_16_10-master/compiler=clang,label=ubuntu_16_10,type=release/13/

[jira] [Updated] (TS-4500) Add cookie-rewrite functionality into header-rewrite plugin

2016-11-07 Thread Bryan Call (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-4500:
---
Summary: Add cookie-rewrite functionality into header-rewrite plugin  (was: 
add cookie-rewrite functionality into header-rewrite plugin)

> Add cookie-rewrite functionality into header-rewrite plugin
> ---
>
> Key: TS-4500
> URL: https://issues.apache.org/jira/browse/TS-4500
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Zhang Zizhong
>Assignee: Zhang Zizhong
> Fix For: 7.0.0
>
>
> add cookie-rewrite functionality into header-rewrite plugin.
> There're three cookie handling operators added, including *add-cookie*, 
> *rm-cookie* and *update-cookie*.
> *add-cookie* adds a key-value pair into Cookie. If the given key is already 
> in Cookie, do nothing.
> *rm-cookie* remove a pair with the given key from Cookie.
> *update-cookie* sets the value with the given key to the given value. If the 
> given key doesn't exist, add a new pair into Cookie. So the only difference 
> between *add-cookie* and *update-cookie* is overwriting an existing pair or 
> not.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-5030) Proposal: Add API to get the client request UUID directly from a TSHttpTx

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5030?focusedWorklogId=31750=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31750
 ]

ASF GitHub Bot logged work on TS-5030:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 23:16
Start Date: 07/Nov/16 23:16
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1184
  
Set the tags to the right please :).


Issue Time Tracking
---

Worklog Id: (was: 31750)
Time Spent: 1h  (was: 50m)

> Proposal: Add API to get the client request UUID directly from a TSHttpTx
> -
>
> Key: TS-5030
> URL: https://issues.apache.org/jira/browse/TS-5030
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: David Calavera
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The new UUID api introduced in 
> https://github.com/apache/trafficserver/pull/736 is great for tracing 
> operations and requests. However, the most useful information for plugin 
> developers, the unique client request id, is not exposed as an api endpoint. 
> People need to understand very well how TrafficServer works internally to 
> generate this value. By not having the API directly exposed, people need to 
> repeat the same code every time they want to generate this unique identifier.
> I'd like to add an API enpoint to generate this identifier based in a given 
> http transaction for plugins to use.
> This would be the signature:
> tsapi const char * TSClientRequestUuidGet(TSHttpTxn txnp);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4994) PANIC: unprotected error in call to Lua API (not enough memory)

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4994?focusedWorklogId=31749=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31749
 ]

ASF GitHub Bot logged work on TS-4994:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 23:15
Start Date: 07/Nov/16 23:15
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1201
  
Set the tags to the right please :).


Issue Time Tracking
---

Worklog Id: (was: 31749)
Time Spent: 1h  (was: 50m)

> PANIC: unprotected error in call to Lua API (not enough memory)
> ---
>
> Key: TS-4994
> URL: https://issues.apache.org/jira/browse/TS-4994
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We have a working installation of TS 6.1; when upgrading to 6.2, it 
> repeatedly crashes almost immediately after startup with:
> {noformat}
> PANIC: unprotected error in call to Lua API (not enough memory)
> pure virtual method called
> terminate called without an active exception
> traffic_server: using root directory '/opt/tbx'
> traffic_server: Aborted (Signal sent by tkill() 11964 33)
> traffic_server - STACK TRACE: 
> /opt/tbx/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ac16e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b2c43b828d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2b2c44b52067]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b2c44b53448]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x15d)[0x2b2c4435bb3d]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ebb6)[0x2b2c44359bb6]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ec01)[0x2b2c44359c01]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f6cf)[0x2b2c4435a6cf]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept18do_blocking_acceptEP7EThread+0x99)[0x74dd69]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept15acceptLoopEventEiP5Event+0x2b)[0x74e62b]
> /opt/tbx/bin/traffic_server(_ZN7EThread7executeEv+0x7f)[0x77ce1f]
> /opt/tbx/bin/traffic_server[0x77c315]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b2c43b7b0a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b2c44c0587d]
> {noformat}
> We have about 5000 lines of Lua, and one C module (lualdap), but nothing that 
> should be approaching Lua's memory limit; it's mostly just access checks that 
> don't allocate any memory at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1197: TS-1257_ssl_cipher_name_table: replace TCL_HashTa...

2016-11-07 Thread zwoop

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1197
  
Set the tags to the right please :).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1184: TS-5030: Add API to get the unique client request...

2016-11-07 Thread zwoop

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1184
  
Set the tags to the right please :).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1201: TS-4994: make state configuration in ts_lua plugi...

2016-11-07 Thread zwoop

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1201
  
Set the tags to the right please :).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1210: Create log_requests plugin

2016-11-07 Thread zwoop

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1210
  
Not sure what happened with my final review message, but I'd suggest 
looking at dump_headers() in e.g. plugins/background_fetch/headers.cc. It 
cleanly dumps all headers into a buffer, which you can then do whatever you 
want with (including dumping with TSError()).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1210: Create log_requests plugin

2016-11-07 Thread zwoop

Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1210#discussion_r86891158
  
--- Diff: plugins/experimental/log_requests/log_requests.c ---
@@ -0,0 +1,301 @@
+/** @file
+
+  Logs full request/response headers on an error response code (4xx/5xx)
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+
+#include "ts/ts.h"
+#include "ts/ink_defs.h"
+
+#define PLUGIN_NAME log_requests
+
+// we log the set of errors in {errors} - {blacklist}
+static TSHttpStatus *blacklist;
+static int blacklist_size; // number of entries in blacklist
+static TSHttpStatus errors[] = {TS_HTTP_STATUS_BAD_REQUEST,
+TS_HTTP_STATUS_UNAUTHORIZED,
+TS_HTTP_STATUS_PAYMENT_REQUIRED,
+TS_HTTP_STATUS_FORBIDDEN,
+TS_HTTP_STATUS_NOT_FOUND,
+TS_HTTP_STATUS_METHOD_NOT_ALLOWED,
+TS_HTTP_STATUS_NOT_ACCEPTABLE,
+
TS_HTTP_STATUS_PROXY_AUTHENTICATION_REQUIRED,
+TS_HTTP_STATUS_REQUEST_TIMEOUT,
+TS_HTTP_STATUS_CONFLICT,
+TS_HTTP_STATUS_GONE,
+TS_HTTP_STATUS_LENGTH_REQUIRED,
+TS_HTTP_STATUS_PRECONDITION_FAILED,
+TS_HTTP_STATUS_REQUEST_ENTITY_TOO_LARGE,
+TS_HTTP_STATUS_REQUEST_URI_TOO_LONG,
+TS_HTTP_STATUS_UNSUPPORTED_MEDIA_TYPE,
+
TS_HTTP_STATUS_REQUESTED_RANGE_NOT_SATISFIABLE,
+TS_HTTP_STATUS_EXPECTATION_FAILED,
+TS_HTTP_STATUS_UNPROCESSABLE_ENTITY,
+TS_HTTP_STATUS_LOCKED,
+TS_HTTP_STATUS_FAILED_DEPENDENCY,
+TS_HTTP_STATUS_UPGRADE_REQUIRED,
+TS_HTTP_STATUS_PRECONDITION_REQUIRED,
+TS_HTTP_STATUS_TOO_MANY_REQUESTS,
+
TS_HTTP_STATUS_REQUEST_HEADER_FIELDS_TOO_LARGE,
+TS_HTTP_STATUS_INTERNAL_SERVER_ERROR,
+TS_HTTP_STATUS_NOT_IMPLEMENTED,
+TS_HTTP_STATUS_BAD_GATEWAY,
+TS_HTTP_STATUS_SERVICE_UNAVAILABLE,
+TS_HTTP_STATUS_GATEWAY_TIMEOUT,
+TS_HTTP_STATUS_HTTPVER_NOT_SUPPORTED,
+TS_HTTP_STATUS_VARIANT_ALSO_NEGOTIATES,
+TS_HTTP_STATUS_INSUFFICIENT_STORAGE,
+TS_HTTP_STATUS_LOOP_DETECTED,
+TS_HTTP_STATUS_NOT_EXTENDED,
+
TS_HTTP_STATUS_NETWORK_AUTHENTICATION_REQUIRED};
+
+static bool should_log(TSHttpTxn txnp);
+static void log_request_line(TSMBuffer bufp, TSMLoc loc, const char 
*output_header);
+static void log_response_status_line(TSMBuffer bufp, TSMLoc loc, const 
char *output_header);
+static void log_headers(TSMBuffer bufp, TSMLoc loc, const char 
*output_header);
+static void log_full_transaction(TSHttpTxn txnp);
+static int log_requests_plugin(TSCont contp ATS_UNUSED, TSEvent event, 
void *edata);
+
+static bool
+should_log(TSHttpTxn txnp)
+{
+  TSMBuffer txn_resp_bufp;
+  TSMLoc txn_resp_loc;
+  TSHttpStatus resp_status;
+
+  if (TSHttpTxnClientRespGet(txnp, _resp_bufp, _resp_loc) != 
TS_SUCCESS) {
+TSError("[log_requests] Couldn't retrieve server response header.");
+return false;
+  }
+
+  // if resp_status is

Jenkins build is back to normal : ubuntu_16_10-master » gcc,ubuntu_16_10,release #13

2016-11-07 Thread jenkins

https://ci.trafficserver.apache.org/job/ubuntu_16_10-master/compiler=gcc,label=ubuntu_16_10,type=release/13/

[jira] [Resolved] (TS-5043) Too many Note() on config reloads

2016-11-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom resolved TS-5043.
---
Resolution: Invalid

> Too many Note() on config reloads
> -
>
> Key: TS-5043
> URL: https://issues.apache.org/jira/browse/TS-5043
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Logging
>Reporter: Leif Hedstrom
>
> Seeing this when I do a "traffic_ctl config reload"
> {code}
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> {code}
> Don't know why, but that seems either wrong, or insanely verbose.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-5044) Too many Note("updated diags config") on config reloads

2016-11-07 Thread Leif Hedstrom (JIRA)

Leif Hedstrom created TS-5044:
-

 Summary: Too many Note("updated diags config") on config reloads
 Key: TS-5044
 URL: https://issues.apache.org/jira/browse/TS-5044
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration, Logging
Reporter: Leif Hedstrom


Seeing this when I do a "traffic_ctl config reload"

{code}
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
{code}

Don't know why, but that seems either wrong, or insanely verbose.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-5044) Too many Note("updated diags config") on config reloads

2016-11-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-5044:
--
Fix Version/s: 7.1.0

> Too many Note("updated diags config") on config reloads
> ---
>
> Key: TS-5044
> URL: https://issues.apache.org/jira/browse/TS-5044
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Logging
>Reporter: Leif Hedstrom
> Fix For: 7.1.0
>
>
> Seeing this when I do a "traffic_ctl config reload"
> {code}
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
> updated diags config
> {code}
> Don't know why, but that seems either wrong, or insanely verbose.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-5043) Too many Note() on config reloads

2016-11-07 Thread Leif Hedstrom (JIRA)

Leif Hedstrom created TS-5043:
-

 Summary: Too many Note() on config reloads
 Key: TS-5043
 URL: https://issues.apache.org/jira/browse/TS-5043
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration, Logging
Reporter: Leif Hedstrom


Seeing this when I do a "traffic_ctl config reload"

{code}
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:37 s_sys@host traffic_manager[12821]: {0x7f3374df0700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
Nov  7 21:21:44 s_sys@host traffic_server[12832]: {0x2aaab3e05700} NOTE: 
updated diags config
{code}

Don't know why, but that seems either wrong, or insanely verbose.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1210: Create log_requests plugin

2016-11-07 Thread danobi

Github user danobi commented on the issue:

https://github.com/apache/trafficserver/pull/1210
  
Created under @SolidWallOfCode 's orders.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1210: Create log_requests plugin

2016-11-07 Thread danobi

GitHub user danobi opened a pull request:

https://github.com/apache/trafficserver/pull/1210

Create log_requests plugin

This plugin records status line & headers for all 4xx/5xx response
transactions. Also included is a blacklist feature to omit any
specific response code transactions. eg. you can choose to not
log transactions with response code 415.

See included README for instructions.

Next steps:
- Include plugin flag to also log proxy request/responses
- Use more robust option parsing

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/danobi/trafficserver log_requests

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1210.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1210


commit 44ea7eca11f043f24be3c75dab9aa9c391efc2bc
Author: Daniel Xu 
Date:   2016-11-07T22:54:41Z

Create log_requests plugin

This plugin records status line & headers for all 4xx/5xx response
transactions. Also included is a blacklist feature to omit any
specific response code transactions. eg. you can choose to not
log transactions with response code 415.

See included README for instructions.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1209: Remove unused and never to be used classes from M...

2016-11-07 Thread zwoop

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1209
  
@SolidWallOfCode You have to fix the unit tests too, in lib/ts/test_Map.cc.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: ubuntu_16_10-master » clang,ubuntu_16_10,release #12

2016-11-07 Thread jenkins

https://ci.trafficserver.apache.org/job/ubuntu_16_10-master/compiler=clang,label=ubuntu_16_10,type=release/12/--
[...truncated 17655 lines...]
*** TEST 62 *** STARTING ***
*** TEST 62 *** PASSED ***
*** TEST 63 *** STARTING ***
*** TEST 63 *** PASSED ***
*** TEST 64 *** STARTING ***
*** TEST 64 *** PASSED ***
*** TEST 65 *** STARTING ***
*** TEST 65 *** PASSED ***
*** TEST 66 *** STARTING ***
*** TEST 66 *** PASSED ***
*** TEST 67 *** STARTING ***
*** TEST 67 *** PASSED ***
*** TEST 68 *** STARTING ***
*** TEST 68 *** PASSED ***
*** TEST 69 *** STARTING ***
*** TEST 69 *** PASSED ***
*** TEST 70 *** STARTING ***
*** TEST 70 *** PASSED ***
*** TEST 71 *** STARTING ***
*** TEST 71 *** PASSED ***
*** TEST 72 *** STARTING ***
*** TEST 72 *** PASSED ***
*** TEST 73 *** STARTING ***
*** TEST 73 *** PASSED ***
*** TEST 74 *** STARTING ***
*** TEST 74 *** PASSED ***
*** TEST 75 *** STARTING ***
*** TEST 75 *** PASSED ***
*** TEST 76 *** STARTING ***
*** TEST 76 *** PASSED ***
*** TEST 77 *** STARTING ***
*** TEST 77 *** PASSED ***
*** TEST 78 *** STARTING ***
*** TEST 78 *** PASSED ***
*** TEST 79 *** STARTING ***
*** TEST 79 *** PASSED ***
*** TEST 80 *** STARTING ***
*** TEST 80 *** PASSED ***
*** TEST 81 *** STARTING ***
*** TEST 81 *** PASSED ***
*** TEST 82 *** STARTING ***
*** TEST 82 *** PASSED ***
*** TEST 83 *** STARTING ***
*** TEST 83 *** PASSED ***
*** TEST 84 *** STARTING ***
*** TEST 84 *** PASSED ***
*** TEST 85 *** STARTING ***
*** TEST 85 *** PASSED ***
*** TEST 86 *** STARTING ***
*** TEST 86 *** PASSED ***
*** TEST 87 *** STARTING ***
*** TEST 87 *** PASSED ***
*** TEST 88 *** STARTING ***
*** TEST 88 *** PASSED ***
*** TEST 89 *** STARTING ***
*** TEST 89 *** PASSED ***
*** TEST 90 *** STARTING ***
*** TEST 90 *** PASSED ***
*** TEST 91 *** STARTING ***
*** TEST 91 *** PASSED ***
*** TEST 92 *** STARTING ***
*** TEST 92 *** PASSED ***
*** TEST 93 *** STARTING ***
*** TEST 93 *** PASSED ***
*** TEST 94 *** STARTING ***
*** TEST 94 *** PASSED ***
*** TEST 95 *** STARTING ***
*** TEST 95 *** PASSED ***
*** TEST 96 *** STARTING ***
*** TEST 96 *** PASSED ***
*** TEST 97 *** STARTING ***
*** TEST 97 *** PASSED ***
*** TEST 98 *** STARTING ***
*** TEST 98 *** PASSED ***
*** TEST 99 *** STARTING ***
*** TEST 99 *** PASSED ***
*** TEST 100 *** STARTING ***
*** TEST 100 *** PASSED ***
*** TEST 101 *** STARTING ***
*** TEST 101 *** PASSED ***
*** TEST 102 *** STARTING ***
*** TEST 102 *** PASSED ***
*** TEST 103 *** STARTING ***
*** TEST 103 *** PASSED ***
*** TEST 104 *** STARTING ***
*** TEST 104 *** PASSED ***
*** TEST 105 *** STARTING ***
*** TEST 105 *** PASSED ***
*** TEST 106 *** STARTING ***
*** TEST 106 *** PASSED ***
*** TEST 107 *** STARTING ***
*** TEST 107 *** PASSED ***
*** TEST 108 *** STARTING ***
*** TEST 108 *** PASSED ***
*** TEST 109 *** STARTING ***
*** TEST 109 *** PASSED ***
*** TEST 110 *** STARTING ***
*** TEST 110 *** PASSED ***
*** TEST 111 *** STARTING ***
*** TEST 111 *** PASSED ***
*** TEST 112 *** STARTING ***
*** TEST 112 *** PASSED ***
*** TEST 113 *** STARTING ***
*** TEST 113 *** PASSED ***
*** TEST 114 *** STARTING ***
*** TEST 114 *** PASSED ***
*** TEST 115 *** STARTING ***
*** TEST 115 *** PASSED ***
*** TEST 116 *** STARTING ***
*** TEST 116 *** PASSED ***
*** TEST 117 *** STARTING ***
*** TEST 117 *** PASSED ***
*** TEST 118 *** STARTING ***
*** TEST 118 *REGRESSION_RESULT PARENTSELECTION:  
PASSED
REGRESSION_TEST DONE: FAILED
** PASSED ***
*** TEST 119 *** STARTING ***
*** TEST 119 *** PASSED ***
*** TEST 120 *** STARTING ***
*** TEST 120 *** PASSED ***
*** TEST 121 *** STARTING ***
*** TEST 121 *** PASSED ***
*** TEST 122 *** STARTING ***
*** TEST 122 *** PASSED ***
*** TEST 123 *** STARTING ***
*** TEST 123 *** PASSED ***
*** TEST 124 *** STARTING ***
*** TEST 124 *** PASSED ***
*** TEST 125 *** STARTING ***
*** TEST 125 *** PASSED ***
*** TEST 126 *** STARTING ***
*** TEST 126 *** PASSED ***
*** TEST 127 *** STARTING ***
*** TEST 127 *** PASSED ***
*** TEST 128 *** STARTING ***
*** TEST 128 *** PASSED ***
*** TEST 129 *** STARTING ***
*** TEST 129 *** PASSED ***
*** TEST 130 *** STARTING ***
*** TEST 130 *** PASSED ***
*** TEST 131 *** STARTING ***
*** TEST 131 *** PASSED ***
*** TEST 132 *** STARTING ***
*** TEST 132 *** PASSED ***
*** TEST 133 *** STARTING ***
*** TEST 133 *** PASSED ***
*** TEST 134 *** STARTING ***
*** TEST 134 *** PASSED ***
*** TEST 135 *** STARTING ***
*** TEST 135 *** PASSED ***
*** TEST 136 *** STARTING ***
*** TEST 136 *** PASSED ***
*** TEST 137 *** STARTING ***
*** TEST 137 *** PASSED ***
*** TEST 138 *** STARTING ***
*** TEST 138 *** PASSED ***
*** TEST 139 *** STARTING ***
*** TEST 139 *** PASSED ***
*** TEST 140 *** STARTING ***
*** TEST 140 *** PASSED ***
*** TEST 141 *** STARTING ***
*** TEST 141 *** PASSED ***
*** TEST 142 *** STARTING ***
*** TEST 142 *** PASSED ***
*** TEST 143 *** STARTING ***
*** TEST 143 *** PASSED ***
*** TEST 144 *** STARTING ***
***

Jenkins build is back to normal : ubuntu_16_10-master » clang,ubuntu_16_10,debug #12

2016-11-07 Thread jenkins

https://ci.trafficserver.apache.org/job/ubuntu_16_10-master/compiler=clang,label=ubuntu_16_10,type=debug/12/

[GitHub] trafficserver issue #1207: Remove unneeded malloc from url_rewrite debug pat...

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1207
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1084/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: ubuntu_16_10-master » gcc,ubuntu_16_10,release #12

2016-11-07 Thread jenkins

https://ci.trafficserver.apache.org/job/ubuntu_16_10-master/compiler=gcc,label=ubuntu_16_10,type=release/12/--
[...truncated 17635 lines...]
*** TEST 62 *** STARTING ***
*** TEST 62 *** PASSED ***
*** TEST 63 *** STARTING ***
*** TEST 63 *** PASSED ***
*** TEST 64 *** STARTING ***
*** TEST 64 *** PASSED ***
*** TEST 65 *** STARTING ***
*** TEST 65 *** PASSED ***
*** TEST 66 *** STARTING ***
*** TEST 66 *** PASSED ***
*** TEST 67 *** STARTING ***
*** TEST 67 *** PASSED ***
*** TEST 68 *** STARTING ***
*** TEST 68 *** PASSED ***
*** TEST 69 *** STARTING ***
*** TEST 69 *** PASSED ***
*** TEST 70 *** STARTING ***
*** TEST 70 *** PASSED ***
*** TEST 71 *** STARTING ***
*** TEST 71 *** PASSED ***
*** TEST 72 *** STARTING ***
*** TEST 72 *** PASSED ***
*** TEST 73 *** STARTING ***
*** TEST 73 *** PASSED ***
*** TEST 74 *** STARTING ***
*** TEST 74 *** PASSED ***
*** TEST 75 *** STARTING ***
*** TEST 75 *** PASSED ***
*** TEST 76 *** STARTING ***
*** TEST 76 *** PASSED ***
*** TEST 77 *** STARTING ***
*** TEST 77 *** PASSED ***
*** TEST 78 *** STARTING ***
*** TEST 78 *** PASSED ***
*** TEST 79 *** STARTING ***
*** TEST 79 *** PASSED ***
*** TEST 80 *** STARTING ***
*** TEST 80 *** PASSED ***
*** TEST 81 *** STARTING ***
*** TEST 81 *** PASSED ***
*** TEST 82 *** STARTING ***
*** TEST 82 *** PASSED ***
*** TEST 83 *** STARTING ***
*** TEST 83 *** PASSED ***
*** TEST 84 *** STARTING ***
*** TEST 84 *** PASSED ***
*** TEST 85 *** STARTING ***
*** TEST 85 *** PASSED ***
*** TEST 86 *** STARTING ***
*** TEST 86 *** PASSED ***
*** TEST 87 *** STARTING ***
*** TEST 87 *** PASSED ***
*** TEST 88 *** STARTING ***
*** TEST 88 *** PASSED ***
*** TEST 89 *** STARTING ***
*** TEST 89 *** PASSED ***
*** TEST 90 *** STARTING ***
*** TEST 90 *** PASSED ***
*** TEST 91 *** STARTING ***
*** TEST 91 *** PASSED ***
*** TEST 92 *** STARTING ***
*** TEST 92 *** PASSED ***
*** TEST 93 *** STARTING ***
*** TEST 93 *** PASSED ***
*** TEST 94 *** STARTING ***
*** TEST 94 *** PASSED ***
*** TEST 95 *** STARTING ***
*** TEST 95 *** PASSED ***
*** TEST 96 *** STARTING ***
*** TEST 96 *** PASSED ***
*** TEST 97 *** STARTING ***
*** TEST 97 *** PASSED ***
*** TEST 98 *** STARTING ***
*** TEST 98 *** PASSED ***
*** TEST 99 *** STARTING ***
*** TEST 99 *** PASSED ***
*** TEST 100 *** STARTING ***
*** TEST 100 *** PASSED ***
*** TEST 101 *** STARTING ***
*** TEST 101 *** PASSED ***
*** TEST 102 *** STARTING ***
*** TEST 102 *** PASSED ***
*** TEST 103 *** STARTING ***
*** TEST 103 *** PASSED ***
*** TEST 104 *** STARTING ***
*** TEST 104 *** PASSED ***
*** TEST 105 *** STARTING ***
*** TEST 105 *** PASSED ***
*** TEST 106 *** STARTING ***
*** TEST 106 *** PASSED ***
*** TEST 107 *** STARTING ***
*** TEST 107 *** PASSED ***
*** TEST 108 *** STARTING ***
*** TEST 108 *** PASSED ***
*** TEST 109 *** STARTING ***
*** TEST 109 *** PASSED ***
*** TEST 110 *** STARTING ***
*** TEST 110 *** PASSED ***
*** TEST 111 *** STARTING ***
*** TEST 111 *** PASSED ***
*** TEST 112 *** STARTING ***
*** TEST 112 *** PASSED ***
*** TEST 113 *** STARTING ***
*** TEST 113 *** PASSED ***
*** TEST 114 *** STARTING ***
*** TEST 114 *** PASSED ***
*** TEST 115 *** STARTING ***
*** TEST 115 *** PASSED ***
*** TEST 116 *** STARTING ***
*** TEST 116 *** PASSED ***
*** TEST 117 *** STARTING ***
*** TEST 117 *** PASSED ***
*** TEST 118 *** STARTING ***
*** TEST 118 ***REGRESSION_RESULT PARENTSELECTION:  
PASSED
REGRESSION_TEST DONE: FAILED
 PASSED ***
*** TEST 119 *** STARTING ***
*** TEST 119 *** PASSED ***
*** TEST 120 *** STARTING ***
*** TEST 120 *** PASSED ***
*** TEST 121 *** STARTING ***
*** TEST 121 *** PASSED ***
*** TEST 122 *** STARTING ***
*** TEST 122 *** PASSED ***
*** TEST 123 *** STARTING ***
*** TEST 123 *** PASSED ***
*** TEST 124 *** STARTING ***
*** TEST 124 *** PASSED ***
*** TEST 125 *** STARTING ***
*** TEST 125 *** PASSED ***
*** TEST 126 *** STARTING ***
*** TEST 126 *** PASSED ***
*** TEST 127 *** STARTING ***
*** TEST 127 *** PASSED ***
*** TEST 128 *** STARTING ***
*** TEST 128 *** PASSED ***
*** TEST 129 *** STARTING ***
*** TEST 129 *** PASSED ***
*** TEST 130 *** STARTING ***
*** TEST 130 *** PASSED ***
*** TEST 131 *** STARTING ***
*** TEST 131 *** PASSED ***
*** TEST 132 *** STARTING ***
*** TEST 132 *** PASSED ***
*** TEST 133 *** STARTING ***
*** TEST 133 *** PASSED ***
*** TEST 134 *** STARTING ***
*** TEST 134 *** PASSED ***
*** TEST 135 *** STARTING ***
*** TEST 135 *** PASSED ***
*** TEST 136 *** STARTING ***
*** TEST 136 *** PASSED ***
*** TEST 137 *** STARTING ***
*** TEST 137 *** PASSED ***
*** TEST 138 *** STARTING ***
*** TEST 138 *** PASSED ***
*** TEST 139 *** STARTING ***
*** TEST 139 *** PASSED ***
*** TEST 140 *** STARTING ***
*** TEST 140 *** PASSED ***
*** TEST 141 *** STARTING ***
*** TEST 141 *** PASSED ***
*** TEST 142 *** STARTING ***
*** TEST 142 *** PASSED ***
*** TEST 143 *** STARTING ***
*** TEST 143 *** PASSED ***
*** TEST 144 *** STARTING ***
***

[GitHub] trafficserver issue #1209: Remove unused and never to be used classes from M...

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1209
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1083/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Jenkins build is back to normal : ubuntu_16_10-master » gcc,ubuntu_16_10,debug #12

2016-11-07 Thread jenkins

https://ci.trafficserver.apache.org/job/ubuntu_16_10-master/compiler=gcc,label=ubuntu_16_10,type=debug/12/

[GitHub] trafficserver issue #1207: Remove unneeded malloc from url_rewrite debug pat...

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1207
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1191/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Failed: trafficserver (dab332a0)

2016-11-07 Thread Read the Docs


Build Failed for trafficserver (latest)



You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4627110/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[GitHub] trafficserver issue #1209: Remove unused and never to be used classes from M...

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1209
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1190/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-5042) Add failcount and threshold values in parent selection logging

2016-11-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-5042:
--
Assignee: Masa Sekimura

> Add failcount and threshold values in parent selection logging
> --
>
> Key: TS-5042
> URL: https://issues.apache.org/jira/browse/TS-5042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Masa Sekimura
>Assignee: Masa Sekimura
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To debug and treak those retry values appropriately, it would be nice to have 
> actual fail count and threshold values in the log.
> https://github.com/apache/trafficserver/pull/1198



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Failed: trafficserver (7f25fa50)

2016-11-07 Thread Read the Docs


Build Failed for trafficserver (latest)



You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4627096/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[jira] [Work logged] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4514?focusedWorklogId=31745=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31745
 ]

ASF GitHub Bot logged work on TS-4514:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 21:45
Start Date: 07/Nov/16 21:45
Worklog Time Spent: 10m 
  Work Description: Github user jrushford closed the pull request at:

https://github.com/apache/trafficserver/pull/1208


Issue Time Tracking
---

Worklog Id: (was: 31745)
Time Spent: 20m  (was: 10m)

> Transaction hangs when no_dns_just_forward is configured but parent proxy is 
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config 
> ATS will keep retrying to resolve the same parent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-5042) Add failcount and threshold values in parent selection logging

2016-11-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-5042:
--
Fix Version/s: 7.1.0

> Add failcount and threshold values in parent selection logging
> --
>
> Key: TS-5042
> URL: https://issues.apache.org/jira/browse/TS-5042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Masa Sekimura
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To debug and treak those retry values appropriately, it would be nice to have 
> actual fail count and threshold values in the log.
> https://github.com/apache/trafficserver/pull/1198



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4514?focusedWorklogId=31743=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31743
 ]

ASF GitHub Bot logged work on TS-4514:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 21:45
Start Date: 07/Nov/16 21:45
Worklog Time Spent: 10m 
  Work Description: GitHub user jrushford opened a pull request:

https://github.com/apache/trafficserver/pull/1208

TS-4514: Transaction hangs when no_dns_just_forward is configured but…

… parent proxy is unresolvable (#699)

It doesn't really make sense for the parent selection layer to be aware of 
the no_dns flag.
Calling code handles takes the flag into account.
(cherry picked from commit 52843c023800370781e69fec45c3952edf8a307b)

Conflicts:
proxy/ParentRoundRobin.cc
proxy/ParentSelection.cc

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jrushford/trafficserver TS-4514

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1208.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1208


commit 9b9b2a30f5fb6331a9ba3e9df2d1a46bb8aa015e
Author: Uri Shachar 
Date:   2016-06-09T07:11:18Z

TS-4514: Transaction hangs when no_dns_just_forward is configured but 
parent proxy is unresolvable (#699)

It doesn't really make sense for the parent selection layer to be aware of 
the no_dns flag.
Calling code handles takes the flag into account.
(cherry picked from commit 52843c023800370781e69fec45c3952edf8a307b)

Conflicts:
proxy/ParentRoundRobin.cc
proxy/ParentSelection.cc




Issue Time Tracking
---

Worklog Id: (was: 31743)
Time Spent: 10m
Remaining Estimate: 0h

> Transaction hangs when no_dns_just_forward is configured but parent proxy is 
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config 
> ATS will keep retrying to resolve the same parent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-5042) Add failcount and threshold values in parent selection logging

2016-11-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-5042:
--
Component/s: Parent Proxy

> Add failcount and threshold values in parent selection logging
> --
>
> Key: TS-5042
> URL: https://issues.apache.org/jira/browse/TS-5042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Masa Sekimura
>Assignee: Masa Sekimura
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To debug and treak those retry values appropriately, it would be nice to have 
> actual fail count and threshold values in the log.
> https://github.com/apache/trafficserver/pull/1198



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-5042) Add failcount and threshold values in parent selection logging

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5042?focusedWorklogId=31744=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31744
 ]

ASF GitHub Bot logged work on TS-5042:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 21:45
Start Date: 07/Nov/16 21:45
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/1198


Issue Time Tracking
---

Worklog Id: (was: 31744)
Time Spent: 10m
Remaining Estimate: 0h

> Add failcount and threshold values in parent selection logging
> --
>
> Key: TS-5042
> URL: https://issues.apache.org/jira/browse/TS-5042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Masa Sekimura
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To debug and treak those retry values appropriately, it would be nice to have 
> actual fail count and threshold values in the log.
> https://github.com/apache/trafficserver/pull/1198



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-5042) Add failcount and threshold values in parent selection logging

2016-11-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom resolved TS-5042.
---
Resolution: Fixed

> Add failcount and threshold values in parent selection logging
> --
>
> Key: TS-5042
> URL: https://issues.apache.org/jira/browse/TS-5042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Masa Sekimura
>Assignee: Masa Sekimura
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To debug and treak those retry values appropriately, it would be nice to have 
> actual fail count and threshold values in the log.
> https://github.com/apache/trafficserver/pull/1198



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1209: Remove unused and never to be used classes...

2016-11-07 Thread SolidWallOfCode

GitHub user SolidWallOfCode opened a pull request:

https://github.com/apache/trafficserver/pull/1209

Remove unused and never to be used classes from Map.h.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SolidWallOfCode/trafficserver 
amc-map-h-cleanup

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1209.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1209


commit e49535a4a6bfe7c2cc9e36539636adaa6d2a
Author: Alan M. Carroll 
Date:   2016-11-07T21:20:47Z

Remove unused and never to be used classes from Map.h.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1198: TS-5042: Add failcount and threshold value...

2016-11-07 Thread zwoop

Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/1198


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1208: TS-4514: Transaction hangs when no_dns_jus...

2016-11-07 Thread jrushford

Github user jrushford closed the pull request at:

https://github.com/apache/trafficserver/pull/1208


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1208: TS-4514: Transaction hangs when no_dns_jus...

2016-11-07 Thread jrushford

GitHub user jrushford opened a pull request:

https://github.com/apache/trafficserver/pull/1208

TS-4514: Transaction hangs when no_dns_just_forward is configured butâ¦

â¦ parent proxy is unresolvable (#699)

It doesn't really make sense for the parent selection layer to be aware of 
the no_dns flag.
Calling code handles takes the flag into account.
(cherry picked from commit 52843c023800370781e69fec45c3952edf8a307b)

Conflicts:
proxy/ParentRoundRobin.cc
proxy/ParentSelection.cc

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jrushford/trafficserver TS-4514

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1208.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1208


commit 9b9b2a30f5fb6331a9ba3e9df2d1a46bb8aa015e
Author: Uri Shachar 
Date:   2016-06-09T07:11:18Z

TS-4514: Transaction hangs when no_dns_just_forward is configured but 
parent proxy is unresolvable (#699)

It doesn't really make sense for the parent selection layer to be aware of 
the no_dns flag.
Calling code handles takes the flag into account.
(cherry picked from commit 52843c023800370781e69fec45c3952edf8a307b)

Conflicts:
proxy/ParentRoundRobin.cc
proxy/ParentSelection.cc




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1207: Remove unneeded malloc from url_rewrite de...

2016-11-07 Thread SolidWallOfCode

GitHub user SolidWallOfCode opened a pull request:

https://github.com/apache/trafficserver/pull/1207

Remove unneeded malloc from url_rewrite debug path for HOST header.

The comments claim to copy to get the terminating null, but that's not 
needed. I tested it and as expected it works fine without the allocation & copy.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SolidWallOfCode/trafficserver 
amc-debug-cleanup-url-rewrite-host-header

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1207.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1207


commit 9feff567ae4e6d700402895ceccb1aad1cd0474f
Author: Alan M. Carroll 
Date:   2016-11-07T21:27:12Z

Remove unneeded malloc from url_rewrite debug path for HOST header.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TS-5042) Add failcount and threshold values in parent selection logging

2016-11-07 Thread Masa Sekimura (JIRA)

Masa Sekimura created TS-5042:
-

 Summary: Add failcount and threshold values in parent selection 
logging
 Key: TS-5042
 URL: https://issues.apache.org/jira/browse/TS-5042
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Masa Sekimura


To debug and treak those retry values appropriately, it would be nice to have 
actual fail count and threshold values in the log.



https://github.com/apache/trafficserver/pull/1198




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1198: Add failcount and threshold values in parent sele...

2016-11-07 Thread jrushford

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/1198
  
@sekimura - this seems reasonable.  Can you create a JIRA ticket to go 
along with this PR and amend the commit message with the JIRA ticket?  The 
commit message would be 
"TS-: Add failcount and threshold values in parent selection 
logging."

thanks


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4879?focusedWorklogId=31739=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31739
 ]

ASF GitHub Bot logged work on TS-4879:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:41
Start Date: 07/Nov/16 17:41
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1205


Issue Time Tracking
---

Worklog Id: (was: 31739)
Time Spent: 5h 10m  (was: 5h)

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1205: TS-4879: NetVC leaks while hyper emergency...

2016-11-07 Thread PSUdaemon

Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1205


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4879:

Backport to Version:   (was: 6.2.1)

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4885) Incorrect checking of fds_throttle and fds_limit

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4885?focusedWorklogId=31738=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31738
 ]

ASF GitHub Bot logged work on TS-4885:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:40
Start Date: 07/Nov/16 17:40
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1204


Issue Time Tracking
---

Worklog Id: (was: 31738)
Time Spent: 1h 20m  (was: 1h 10m)

> Incorrect checking of fds_throttle and fds_limit
> 
>
> Key: TS-4885
> URL: https://issues.apache.org/jira/browse/TS-4885
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> {code}
>  902 static void
>  903 check_fd_limit()
>  904 {
>  905   int fds_throttle = -1;
>  906   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
>  907   if (fds_throttle > fds_limit + THROTTLE_FD_HEADROOM) {  // 
> ---> Incorrect
>  908 int new_fds_throttle = fds_limit - THROTTLE_FD_HEADROOM;
>  909 if (new_fds_throttle < 1) {
>  910   ink_abort("too few file descriptors (%d) available", fds_limit);
>  911 }
>  912 char msg[256];
>  913 snprintf(msg, sizeof(msg), "connection throttle too high, "
>  914"%d (throttle) + %d (internal use) > %d 
> (file descriptor limit), "
>  915"using throttle of %d",
>  916  fds_throttle, THROTTLE_FD_HEADROOM, fds_limit, 
> new_fds_throttle);
>  917 SignalWarning(MGMT_SIGNAL_SYSTEM_ERROR, msg);
>  918   }
>  919 }
> {code}
> {code}
> 1001 static void
> 1002 adjust_sys_settings(void)
> 1003 {
> ...
> 1024   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
> 1025 
> 1026   if (getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1027 if (fds_throttle > (int)(lim.rlim_cur + THROTTLE_FD_HEADROOM)) {  // 
> --> Incorrect
> 1028   lim.rlim_cur = (lim.rlim_max = (rlim_t)fds_throttle);
> 1029   if (setrlimit(RLIMIT_NOFILE, ) == 0 && 
> getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1030 fds_limit = (int)lim.rlim_cur;
> 1031 syslog(LOG_NOTICE, "NOTE: RLIMIT_NOFILE(%d):cur(%d),max(%d)", 
> RLIMIT_NOFILE, (int)lim.rlim_cur, (int)lim.rlim_max);
> 1032   }
> 1033 }
> 1034   }
> ...
> 1043 }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4885) Incorrect checking of fds_throttle and fds_limit

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4885:

Fix Version/s: 6.2.1

> Incorrect checking of fds_throttle and fds_limit
> 
>
> Key: TS-4885
> URL: https://issues.apache.org/jira/browse/TS-4885
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {code}
>  902 static void
>  903 check_fd_limit()
>  904 {
>  905   int fds_throttle = -1;
>  906   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
>  907   if (fds_throttle > fds_limit + THROTTLE_FD_HEADROOM) {  // 
> ---> Incorrect
>  908 int new_fds_throttle = fds_limit - THROTTLE_FD_HEADROOM;
>  909 if (new_fds_throttle < 1) {
>  910   ink_abort("too few file descriptors (%d) available", fds_limit);
>  911 }
>  912 char msg[256];
>  913 snprintf(msg, sizeof(msg), "connection throttle too high, "
>  914"%d (throttle) + %d (internal use) > %d 
> (file descriptor limit), "
>  915"using throttle of %d",
>  916  fds_throttle, THROTTLE_FD_HEADROOM, fds_limit, 
> new_fds_throttle);
>  917 SignalWarning(MGMT_SIGNAL_SYSTEM_ERROR, msg);
>  918   }
>  919 }
> {code}
> {code}
> 1001 static void
> 1002 adjust_sys_settings(void)
> 1003 {
> ...
> 1024   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
> 1025 
> 1026   if (getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1027 if (fds_throttle > (int)(lim.rlim_cur + THROTTLE_FD_HEADROOM)) {  // 
> --> Incorrect
> 1028   lim.rlim_cur = (lim.rlim_max = (rlim_t)fds_throttle);
> 1029   if (setrlimit(RLIMIT_NOFILE, ) == 0 && 
> getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1030 fds_limit = (int)lim.rlim_cur;
> 1031 syslog(LOG_NOTICE, "NOTE: RLIMIT_NOFILE(%d):cur(%d),max(%d)", 
> RLIMIT_NOFILE, (int)lim.rlim_cur, (int)lim.rlim_max);
> 1032   }
> 1033 }
> 1034   }
> ...
> 1043 }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4885) Incorrect checking of fds_throttle and fds_limit

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4885:

Backport to Version:   (was: 6.2.1)

> Incorrect checking of fds_throttle and fds_limit
> 
>
> Key: TS-4885
> URL: https://issues.apache.org/jira/browse/TS-4885
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {code}
>  902 static void
>  903 check_fd_limit()
>  904 {
>  905   int fds_throttle = -1;
>  906   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
>  907   if (fds_throttle > fds_limit + THROTTLE_FD_HEADROOM) {  // 
> ---> Incorrect
>  908 int new_fds_throttle = fds_limit - THROTTLE_FD_HEADROOM;
>  909 if (new_fds_throttle < 1) {
>  910   ink_abort("too few file descriptors (%d) available", fds_limit);
>  911 }
>  912 char msg[256];
>  913 snprintf(msg, sizeof(msg), "connection throttle too high, "
>  914"%d (throttle) + %d (internal use) > %d 
> (file descriptor limit), "
>  915"using throttle of %d",
>  916  fds_throttle, THROTTLE_FD_HEADROOM, fds_limit, 
> new_fds_throttle);
>  917 SignalWarning(MGMT_SIGNAL_SYSTEM_ERROR, msg);
>  918   }
>  919 }
> {code}
> {code}
> 1001 static void
> 1002 adjust_sys_settings(void)
> 1003 {
> ...
> 1024   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
> 1025 
> 1026   if (getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1027 if (fds_throttle > (int)(lim.rlim_cur + THROTTLE_FD_HEADROOM)) {  // 
> --> Incorrect
> 1028   lim.rlim_cur = (lim.rlim_max = (rlim_t)fds_throttle);
> 1029   if (setrlimit(RLIMIT_NOFILE, ) == 0 && 
> getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1030 fds_limit = (int)lim.rlim_cur;
> 1031 syslog(LOG_NOTICE, "NOTE: RLIMIT_NOFILE(%d):cur(%d),max(%d)", 
> RLIMIT_NOFILE, (int)lim.rlim_cur, (int)lim.rlim_max);
> 1032   }
> 1033 }
> 1034   }
> ...
> 1043 }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4879:

Fix Version/s: 6.2.1

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1204: TS-4885: Correct the calculation of fds_th...

2016-11-07 Thread PSUdaemon

Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1204


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1203: TS-2482: Should use target_addr instead of...

2016-11-07 Thread PSUdaemon

Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1203


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4697:

Fix Version/s: 6.2.1

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2482) Problems with SOCKS

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-2482:

Fix Version/s: 6.2.1

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2482) Problems with SOCKS

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-2482:

Backport to Version:   (was: 6.2.1)

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-2482) Problems with SOCKS

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-2482?focusedWorklogId=31737=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31737
 ]

ASF GitHub Bot logged work on TS-2482:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:39
Start Date: 07/Nov/16 17:39
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1203


Issue Time Tracking
---

Worklog Id: (was: 31737)
Time Spent: 3h 10m  (was: 3h)

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4697:

Backport to Version:   (was: 6.2.1)

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4697?focusedWorklogId=31736=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31736
 ]

ASF GitHub Bot logged work on TS-4697:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:38
Start Date: 07/Nov/16 17:38
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1200


Issue Time Tracking
---

Worklog Id: (was: 31736)
Time Spent: 5h  (was: 4h 50m)

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4614) In UnixNetVConnection::mainEvent should not do e->schedule_in for dummy event callback

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4614:

Backport to Version:   (was: 6.2.1)

> In UnixNetVConnection::mainEvent should not do e->schedule_in for dummy event 
> callback 
> ---
>
> Key: TS-4614
> URL: https://issues.apache.org/jira/browse/TS-4614
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> NetHandler has a method: _close_vc ， It is called by InactivityCop.
> first, create a dummy Event in stack,
> then call UnixNetVConnection::mainEvent by vc->handleEvent(EVENT_IMMEDIATE, 
> );
> the handleEvent is mainEvent here.
> In the UnixNetVConnection::mainEvent code:
> ```
> int
> UnixNetVConnection::mainEvent(int event, Event *e)
> {
>   ink_assert(event == EVENT_IMMEDIATE || event == EVENT_INTERVAL);
>   ink_assert(thread == this_ethread());
>   MUTEX_TRY_LOCK(hlock, get_NetHandler(thread)->mutex, e->ethread);
>   MUTEX_TRY_LOCK(rlock, read.vio.mutex ? read.vio.mutex : e->ethread->mutex, 
> e->ethread);
>   MUTEX_TRY_LOCK(wlock, write.vio.mutex ? write.vio.mutex : 
> e->ethread->mutex, e->ethread);
>   if (!hlock.is_locked() || !rlock.is_locked() || !wlock.is_locked() ||
>   (read.vio.mutex && rlock.get_mutex() != read.vio.mutex.get()) ||
>   (write.vio.mutex && wlock.get_mutex() != write.vio.mutex.get())) {
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
> #endif
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> return EVENT_CONT;
>   }
> ```
> the dummy Event would be schedule_in into Event System by 
> e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> I think we should move the schedule_in into the INACTIVITY_TIMEOUT macro.
> ```
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> #endif
> ```
> I'm try to allocate a Event instead dummy Event, but meet Event System 
> callback on a deallocated UnixNetVConnection.
> due to NetHandler called close_UnixNetVConnection before Event System 
> callback the Event by schedule_in.
> In NetHandler::_close_vc, depend the return value (EVENT_DONE or EVENT_CONT) 
> from UnixNetVConnection::mainEvent, to do ++handle_event; or not.
> ```
> if (vc->handleEvent(EVENT_IMMEDIATE, ) == EVENT_DONE)
>   ++handle_event;
> ```
> the 3 MUTEX_TRY_LOCK not always success on InactivityCop callback,
> due to the mutex of ServerSessionVC may different from ClientSessionVC.
> Only mutex of ServerSession is set to HttpSM when HttpSM pick up a Server 
> Session from SessionPool. ServerSessionVC still keep the old mutex.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4614) In UnixNetVConnection::mainEvent should not do e->schedule_in for dummy event callback

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4614?focusedWorklogId=31735=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31735
 ]

ASF GitHub Bot logged work on TS-4614:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:38
Start Date: 07/Nov/16 17:38
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1199


Issue Time Tracking
---

Worklog Id: (was: 31735)
Time Spent: 2h 10m  (was: 2h)

> In UnixNetVConnection::mainEvent should not do e->schedule_in for dummy event 
> callback 
> ---
>
> Key: TS-4614
> URL: https://issues.apache.org/jira/browse/TS-4614
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> NetHandler has a method: _close_vc ， It is called by InactivityCop.
> first, create a dummy Event in stack,
> then call UnixNetVConnection::mainEvent by vc->handleEvent(EVENT_IMMEDIATE, 
> );
> the handleEvent is mainEvent here.
> In the UnixNetVConnection::mainEvent code:
> ```
> int
> UnixNetVConnection::mainEvent(int event, Event *e)
> {
>   ink_assert(event == EVENT_IMMEDIATE || event == EVENT_INTERVAL);
>   ink_assert(thread == this_ethread());
>   MUTEX_TRY_LOCK(hlock, get_NetHandler(thread)->mutex, e->ethread);
>   MUTEX_TRY_LOCK(rlock, read.vio.mutex ? read.vio.mutex : e->ethread->mutex, 
> e->ethread);
>   MUTEX_TRY_LOCK(wlock, write.vio.mutex ? write.vio.mutex : 
> e->ethread->mutex, e->ethread);
>   if (!hlock.is_locked() || !rlock.is_locked() || !wlock.is_locked() ||
>   (read.vio.mutex && rlock.get_mutex() != read.vio.mutex.get()) ||
>   (write.vio.mutex && wlock.get_mutex() != write.vio.mutex.get())) {
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
> #endif
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> return EVENT_CONT;
>   }
> ```
> the dummy Event would be schedule_in into Event System by 
> e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> I think we should move the schedule_in into the INACTIVITY_TIMEOUT macro.
> ```
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> #endif
> ```
> I'm try to allocate a Event instead dummy Event, but meet Event System 
> callback on a deallocated UnixNetVConnection.
> due to NetHandler called close_UnixNetVConnection before Event System 
> callback the Event by schedule_in.
> In NetHandler::_close_vc, depend the return value (EVENT_DONE or EVENT_CONT) 
> from UnixNetVConnection::mainEvent, to do ++handle_event; or not.
> ```
> if (vc->handleEvent(EVENT_IMMEDIATE, ) == EVENT_DONE)
>   ++handle_event;
> ```
> the 3 MUTEX_TRY_LOCK not always success on InactivityCop callback,
> due to the mutex of ServerSessionVC may different from ClientSessionVC.
> Only mutex of ServerSession is set to HttpSM when HttpSM pick up a Server 
> Session from SessionPool. ServerSessionVC still keep the old mutex.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1200: TS-4697: Free MIOBuffer if the ipallow che...

2016-11-07 Thread PSUdaemon

Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1200


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4614) In UnixNetVConnection::mainEvent should not do e->schedule_in for dummy event callback

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4614:

Fix Version/s: 6.2.1

> In UnixNetVConnection::mainEvent should not do e->schedule_in for dummy event 
> callback 
> ---
>
> Key: TS-4614
> URL: https://issues.apache.org/jira/browse/TS-4614
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> NetHandler has a method: _close_vc ， It is called by InactivityCop.
> first, create a dummy Event in stack,
> then call UnixNetVConnection::mainEvent by vc->handleEvent(EVENT_IMMEDIATE, 
> );
> the handleEvent is mainEvent here.
> In the UnixNetVConnection::mainEvent code:
> ```
> int
> UnixNetVConnection::mainEvent(int event, Event *e)
> {
>   ink_assert(event == EVENT_IMMEDIATE || event == EVENT_INTERVAL);
>   ink_assert(thread == this_ethread());
>   MUTEX_TRY_LOCK(hlock, get_NetHandler(thread)->mutex, e->ethread);
>   MUTEX_TRY_LOCK(rlock, read.vio.mutex ? read.vio.mutex : e->ethread->mutex, 
> e->ethread);
>   MUTEX_TRY_LOCK(wlock, write.vio.mutex ? write.vio.mutex : 
> e->ethread->mutex, e->ethread);
>   if (!hlock.is_locked() || !rlock.is_locked() || !wlock.is_locked() ||
>   (read.vio.mutex && rlock.get_mutex() != read.vio.mutex.get()) ||
>   (write.vio.mutex && wlock.get_mutex() != write.vio.mutex.get())) {
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
> #endif
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> return EVENT_CONT;
>   }
> ```
> the dummy Event would be schedule_in into Event System by 
> e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> I think we should move the schedule_in into the INACTIVITY_TIMEOUT macro.
> ```
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> #endif
> ```
> I'm try to allocate a Event instead dummy Event, but meet Event System 
> callback on a deallocated UnixNetVConnection.
> due to NetHandler called close_UnixNetVConnection before Event System 
> callback the Event by schedule_in.
> In NetHandler::_close_vc, depend the return value (EVENT_DONE or EVENT_CONT) 
> from UnixNetVConnection::mainEvent, to do ++handle_event; or not.
> ```
> if (vc->handleEvent(EVENT_IMMEDIATE, ) == EVENT_DONE)
>   ++handle_event;
> ```
> the 3 MUTEX_TRY_LOCK not always success on InactivityCop callback,
> due to the mutex of ServerSessionVC may different from ClientSessionVC.
> Only mutex of ServerSession is set to HttpSM when HttpSM pick up a Server 
> Session from SessionPool. ServerSessionVC still keep the old mutex.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1199: TS-4614: avoid e->schedule_in for dummy ev...

2016-11-07 Thread PSUdaemon

Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1199


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1206: TS-4838: CONNECT requests get forgotten ac...

2016-11-07 Thread PSUdaemon

Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1206


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4838:

Fix Version/s: 6.2.1

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

2016-11-07 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber updated TS-4838:

Backport to Version:   (was: 6.2.1)

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4838?focusedWorklogId=31734=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31734
 ]

ASF GitHub Bot logged work on TS-4838:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:36
Start Date: 07/Nov/16 17:36
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1206


Issue Time Tracking
---

Worklog Id: (was: 31734)
Time Spent: 1.5h  (was: 1h 20m)

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4838?focusedWorklogId=31733=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31733
 ]

ASF GitHub Bot logged work on TS-4838:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:30
Start Date: 07/Nov/16 17:30
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1206
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1189/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 31733)
Time Spent: 1h 20m  (was: 1h 10m)

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1206: TS-4838: CONNECT requests get forgotten across th...

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1206
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1189/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4838?focusedWorklogId=31732=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31732
 ]

ASF GitHub Bot logged work on TS-4838:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:26
Start Date: 07/Nov/16 17:26
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1206
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1082/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 31732)
Time Spent: 1h 10m  (was: 1h)

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1206: TS-4838: CONNECT requests get forgotten across th...

2016-11-07 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1206
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1082/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1206: TS-4838: CONNECT requests get forgotten ac...

2016-11-07 Thread PSUdaemon

GitHub user PSUdaemon opened a pull request:

https://github.com/apache/trafficserver/pull/1206

TS-4838: CONNECT requests get forgotten across threads.

What happens here is that ProxyClientTransaction::adjust_thread
reschedules the transaction onto a new thread at the start of
HttpSM::do_http_server_open.

Unfortunately, at this point the default handler is
HttpSM::state_raw_http_server_open. When the transaction is
rescheduled, the default handler runs, and receives the EVENT_INTERVAL
that it so fortuitously logs an error for. We have never actually
completed do_http_server_open, so we never make any more progress
on this transaction.

(cherry picked from commit 8fddd77c085d1a64f11de61bb42a50562cd23229)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PSUdaemon/trafficserver bp-1002

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1206.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1206


commit c5ab2e686ac0dad4ebe89573cdcc0b2d2a6359a4
Author: James Peach 
Date:   2016-09-09T22:29:05Z

TS-4838: CONNECT requests get forgotten across threads.

What happens here is that ProxyClientTransaction::adjust_thread
reschedules the transaction onto a new thread at the start of
HttpSM::do_http_server_open.

Unfortunately, at this point the default handler is
HttpSM::state_raw_http_server_open. When the transaction is
rescheduled, the default handler runs, and receives the EVENT_INTERVAL
that it so fortuitously logs an error for. We have never actually
completed do_http_server_open, so we never make any more progress
on this transaction.

(cherry picked from commit 8fddd77c085d1a64f11de61bb42a50562cd23229)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4838?focusedWorklogId=31730=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31730
 ]

ASF GitHub Bot logged work on TS-4838:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 17:16
Start Date: 07/Nov/16 17:16
Worklog Time Spent: 10m 
  Work Description: GitHub user PSUdaemon opened a pull request:

https://github.com/apache/trafficserver/pull/1206

TS-4838: CONNECT requests get forgotten across threads.

What happens here is that ProxyClientTransaction::adjust_thread
reschedules the transaction onto a new thread at the start of
HttpSM::do_http_server_open.

Unfortunately, at this point the default handler is
HttpSM::state_raw_http_server_open. When the transaction is
rescheduled, the default handler runs, and receives the EVENT_INTERVAL
that it so fortuitously logs an error for. We have never actually
completed do_http_server_open, so we never make any more progress
on this transaction.

(cherry picked from commit 8fddd77c085d1a64f11de61bb42a50562cd23229)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PSUdaemon/trafficserver bp-1002

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1206.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1206


commit c5ab2e686ac0dad4ebe89573cdcc0b2d2a6359a4
Author: James Peach 
Date:   2016-09-09T22:29:05Z

TS-4838: CONNECT requests get forgotten across threads.

What happens here is that ProxyClientTransaction::adjust_thread
reschedules the transaction onto a new thread at the start of
HttpSM::do_http_server_open.

Unfortunately, at this point the default handler is
HttpSM::state_raw_http_server_open. When the transaction is
rescheduled, the default handler runs, and receives the EVENT_INTERVAL
that it so fortuitously logs an error for. We have never actually
completed do_http_server_open, so we never make any more progress
on this transaction.

(cherry picked from commit 8fddd77c085d1a64f11de61bb42a50562cd23229)




Issue Time Tracking
---

Worklog Id: (was: 31730)
Time Spent: 1h  (was: 50m)

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the

[jira] [Work logged] (TS-5040) Forward CONNECT methods without parent proxying.

2016-11-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-5040?focusedWorklogId=31727=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31727
 ]

ASF GitHub Bot logged work on TS-5040:
--

Author: ASF GitHub Bot
Created on: 07/Nov/16 15:09
Start Date: 07/Nov/16 15:09
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
No docs for the new setting?


Issue Time Tracking
---

Worklog Id: (was: 31727)
Time Spent: 50m  (was: 40m)

> Forward CONNECT methods without parent proxying.
> 
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the 
> normal remap path cannot. Bring this capability to the remap state machine so 
> that plugins can do the same thing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1202: TS-5040: Forward CONNECT without parent proxying.

2016-11-07 Thread zwoop

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1202
  
No docs for the new setting?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1175: socks.config - dest_ip rule issue

2016-11-07 Thread 06chaynes

Github user 06chaynes commented on the issue:

https://github.com/apache/trafficserver/issues/1175
  
@oknet Very cool, will 6.2.1 be added as a release and propagated through 
the master sites?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

94 matches

Mail list logo