[jira] [Work logged] (TS-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:56
Start Date: 06/Oct/16 21:56
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver issue #1084: TS-4701: Add a new latched parent selection strat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1084
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/946/ 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 issue #1084: TS-4701: Add a new latched parent selection strat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1084
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/838/ 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-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:49
Start Date: 06/Oct/16 21:49
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[jira] [Work logged] (TS-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:47
Start Date: 06/Oct/16 21:47
Worklog Time Spent: 10m 
  Work Description: Github user jrushford commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1084#discussion_r82292764
  
--- Diff: doc/admin-guide/files/parent.config.en.rst ---
@@ -207,6 +207,13 @@ The following list shows the possible actions and 
their allowed values.
The other traffic is unaffected. Once the downed parent becomes
available, the traffic distribution returns to the pre-down
state.
+- ``latched`` - The first parent in the list is marked as primary and 
is 
+  always chosen until connection errors cause it to be marked down.  
When 
+  this occurs the next parent in the list then becomes primary.  The 
primary
+  will wrap back to the first parent in the list when it is the last 
parent
+  in the list and is marked down due to a connection error.  Newly 
chosen
+  primary parents marked as unavilable will then be restored if the 
failure
--- End diff --

thanks, i've fixed that.


Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver pull request #1084: TS-4701: Add a new latched parent selectio...

[jrushford]

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

https://github.com/apache/trafficserver/pull/1084#discussion_r82292764
  
--- Diff: doc/admin-guide/files/parent.config.en.rst ---
@@ -207,6 +207,13 @@ The following list shows the possible actions and 
their allowed values.
The other traffic is unaffected. Once the downed parent becomes
available, the traffic distribution returns to the pre-down
state.
+- ``latched`` - The first parent in the list is marked as primary and 
is 
+  always chosen until connection errors cause it to be marked down.  
When 
+  this occurs the next parent in the list then becomes primary.  The 
primary
+  will wrap back to the first parent in the list when it is the last 
parent
+  in the list and is marked down due to a connection error.  Newly 
chosen
+  primary parents marked as unavilable will then be restored if the 
failure
--- End diff --

thanks, i've fixed that.


---
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-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:40
Start Date: 06/Oct/16 21:40
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1084#discussion_r82291438
  
--- Diff: doc/admin-guide/files/parent.config.en.rst ---
@@ -207,6 +207,13 @@ The following list shows the possible actions and 
their allowed values.
The other traffic is unaffected. Once the downed parent becomes
available, the traffic distribution returns to the pre-down
state.
+- ``latched`` - The first parent in the list is marked as primary and 
is 
+  always chosen until connection errors cause it to be marked down.  
When 
+  this occurs the next parent in the list then becomes primary.  The 
primary
+  will wrap back to the first parent in the list when it is the last 
parent
+  in the list and is marked down due to a connection error.  Newly 
chosen
+  primary parents marked as unavilable will then be restored if the 
failure
--- End diff --

s/unavilable/unavailable/


Issue Time Tracking
---

Worklog Id: (was: 30247)
Time Spent: 1h 40m  (was: 1.5h)

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver pull request #1084: TS-4701: Add a new latched parent selectio...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1084#discussion_r82291438
  
--- Diff: doc/admin-guide/files/parent.config.en.rst ---
@@ -207,6 +207,13 @@ The following list shows the possible actions and 
their allowed values.
The other traffic is unaffected. Once the downed parent becomes
available, the traffic distribution returns to the pre-down
state.
+- ``latched`` - The first parent in the list is marked as primary and 
is 
+  always chosen until connection errors cause it to be marked down.  
When 
+  this occurs the next parent in the list then becomes primary.  The 
primary
+  will wrap back to the first parent in the list when it is the last 
parent
+  in the list and is marked down due to a connection error.  Newly 
chosen
+  primary parents marked as unavilable will then be restored if the 
failure
--- End diff --

s/unavilable/unavailable/


---
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-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:34
Start Date: 06/Oct/16 21:34
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver issue #1084: TS-4701: Add a new latched parent selection strat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1084
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/837/ 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-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:34
Start Date: 06/Oct/16 21:34
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver issue #1084: TS-4701: Add a new latched parent selection strat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1084
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/945/ 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-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:22
Start Date: 06/Oct/16 21:22
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1084#discussion_r82288142
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

Ok, I guess that is just an unfortunate name for that enum.


Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver pull request #1084: TS-4701: Add a new latched parent selectio...

[PSUdaemon]

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

https://github.com/apache/trafficserver/pull/1084#discussion_r82288142
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

Ok, I guess that is just an unfortunate name for that enum.


---
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 #1084: TS-4701: Add a new latched parent selectio...

[jrushford]

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

https://github.com/apache/trafficserver/pull/1084#discussion_r82285415
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

Oops, I'll fix that.  

The interfaces are defined in ParentSelection.h and the enum is used in 
both ParentSelection.cc, ParentConsistentHash.cc and ParentRoundRobin.cc all of 
which include ParentSelection.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.
---

[jira] [Work logged] (TS-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 21:07
Start Date: 06/Oct/16 21:07
Worklog Time Spent: 10m 
  Work Description: Github user jrushford commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1084#discussion_r82285415
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

Oops, I'll fix that.  

The interfaces are defined in ParentSelection.h and the enum is used in 
both ParentSelection.cc, ParentConsistentHash.cc and ParentRoundRobin.cc all of 
which include ParentSelection.h


Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[jira] [Work logged] (TS-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 20:55
Start Date: 06/Oct/16 20:55
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1084#discussion_r82283074
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

@jpeach the previous form is the more desirable one, no?


Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver pull request #1084: TS-4701: Add a new latched parent selectio...

[PSUdaemon]

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

https://github.com/apache/trafficserver/pull/1084#discussion_r82283074
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

@jpeach the previous form is the more desirable one, no?


---
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-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 20:55
Start Date: 06/Oct/16 20:55
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 30241)
Time Spent: 40m  (was: 0.5h)

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver issue #1084: TS-4701: Add a new latched parent selection strat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1084
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/836/ 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 issue #1084: TS-4701: Add a new latched parent selection strat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1084
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/944/ 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-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver pull request #1084: TS-4701: Add a new latched parent selectio...

[PSUdaemon]

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

https://github.com/apache/trafficserver/pull/1084#discussion_r82281304
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

What happened here?

Also, how come this isn't defined in `ParentRoundRobin.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.
---

[jira] [Work logged] (TS-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 20:51
Start Date: 06/Oct/16 20:51
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1084#discussion_r82281304
  
--- Diff: proxy/ParentSelection.h ---
@@ -59,12 +59,7 @@ enum ParentResultType {
   PARENT_FAIL,
 };
 
-enum ParentRR_t {
-  P_NO_ROUND_ROBIN = 0,
-  P_STRICT_ROUND_ROBIN,
-  P_HASH_ROUND_ROBIN,
-  P_CONSISTENT_HASH,
-};
+enum ParentRR_t { P_NO_ROUND_ROBIN = 0, P_STRICT_ROUND_ROBIN, 
P_HASH_ROUND_ROBIN, P_CONSISTENT_HASH, P_LATCHED_ROUND_ROBIN };
--- End diff --

What happened here?

Also, how come this isn't defined in `ParentRoundRobin.h`


Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[jira] [Work logged] (TS-4701) Add a new latched parent selection strategy.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 20:37
Start Date: 06/Oct/16 20:37
Worklog Time Spent: 10m 
  Work Description: GitHub user jrushford opened a pull request:

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

TS-4701: Add a new latched parent selection strategy.

Add a new "latched" round  robin parent selection strategy.  A primary 
parent is chosen from the first parent in the parent list and is always 
returned as the resulting call to findParent().  When connection failure occurs 
and the primary parent is marked down, the state changes the primary to the 
next parent in the list and remains latched until the state is changed when a 
error causes the primary parent to be marked down.  

This strategy is helpful for delivery of live video.  A failure and switch 
to a new parent origin will cause a video client to retune as the manifest and 
video fragment names between origins are different.  With the other strategies, 
once the retry time for a marked down parent has elapsed, another switch and 
retune may occur.  To keep retunes to a minimum, this strategy "latches" state 
to always use the same healthy parent.

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

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

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

https://github.com/apache/trafficserver/pull/1084.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 #1084


commit ebcf828ae6300db7d770abc35fef16a8b9c82e89
Author: John J. Rushford 
Date:   2016-10-06T20:22:59Z

TS-4701: Add a new latched parent selection strategy.




Issue Time Tracking
---

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

> Add a new latched parent selection strategy.
> 
>
> Key: TS-4701
> URL: https://issues.apache.org/jira/browse/TS-4701
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: sometime
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For live linear video we are utilizing parent selection to round robin to 
> origin servers in the event of a origin server failure, parent_is_proxy=false 
> and  round_robin=false.  With this round robin strategy, the first parent in 
> the parent.config list is always selected.  In the event of a connection 
> failure, a new parent is selected from the list.  This works fine except that 
> switching to a new parent is expensive, in that the client has to retune 
> because the abr manifests between origins are different.  A single retune can 
> be tolerated but, after the parent retry time has elapsed, the round robin 
> strategy will revert back to the original parent when it becomes available.  
> This causes a second retune.  In order to minimize client retuning, I'd like 
> to add a new round robin strategy that is similar to round_robin=false but 
> the new strategy would stay "latched" to the selected parent and remain 
> "latched" until such time that a connection failure warrants using a new 
> parent.  I propose calling this strategy "latched" as in an electronic latch 
> that becomes fixed in a particular state when triggered.  This strategy would 
> be a minor modification to ParentRoundRobin and ParentSelection.



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

[GitHub] trafficserver pull request #1084: TS-4701: Add a new latched parent selectio...

[jrushford]

GitHub user jrushford opened a pull request:

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

TS-4701: Add a new latched parent selection strategy.

Add a new "latched" round  robin parent selection strategy.  A primary 
parent is chosen from the first parent in the parent list and is always 
returned as the resulting call to findParent().  When connection failure occurs 
and the primary parent is marked down, the state changes the primary to the 
next parent in the list and remains latched until the state is changed when a 
error causes the primary parent to be marked down.  

This strategy is helpful for delivery of live video.  A failure and switch 
to a new parent origin will cause a video client to retune as the manifest and 
video fragment names between origins are different.  With the other strategies, 
once the retry time for a marked down parent has elapsed, another switch and 
retune may occur.  To keep retunes to a minimum, this strategy "latches" state 
to always use the same healthy parent.

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

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

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

https://github.com/apache/trafficserver/pull/1084.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 #1084


commit ebcf828ae6300db7d770abc35fef16a8b9c82e89
Author: John J. Rushford 
Date:   2016-10-06T20:22:59Z

TS-4701: Add a new latched parent selection strategy.




---
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] [Commented] (TS-4915) Crash from hostdb in PriorityQueueLess

[Susan Hinrichs (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552510#comment-15552510
 ] 

Susan Hinrichs commented on TS-4915:


Still getting these crashes once every couple hours in production traffic.

> Crash from hostdb in PriorityQueueLess
> --
>
> Key: TS-4915
> URL: https://issues.apache.org/jira/browse/TS-4915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
>
> Saw this while testing fix for TS-4813 with debug enabled.
> {code}
> (gdb) bt full
> #0  0x00547bfe in RefCountCacheHashEntry::operator< (this=0x1cc0880, 
> v2=...) at ../iocore/hostdb/P_RefCountCache.h:94
> No locals.
> #1  0x0054988d in 
> PriorityQueueLess::operator() (this=0x2b78a9a2587b, 
> a=@0x2b78f402af68, b=@0x2b78f402aa28)
> at ../lib/ts/PriorityQueue.h:41
> No locals.
> #2  0x00549785 in PriorityQueue PriorityQueueLess >::_bubble_up (this=0x1cb2990, 
> index=2) at ../lib/ts/PriorityQueue.h:191
> comp = {}
> parent = 0
> #3  0x006ecfcc in PriorityQueue PriorityQueueLess >::push (this=0x1cb2990, 
> entry=0x2b78f402af60) at ../../lib/ts/PriorityQueue.h:91
> len = 2
> #4  0x006ec206 in RefCountCachePartition::put 
> (this=0x1cb2900, key=6912554662447498853, item=0x2b78aee04f00, size=96, 
> expire_time=1475202356) at ./P_RefCountCache.h:210
> expiry_entry = 0x2b78f402af60
> __func__ = "put"
> val = 0x1cc0880
> #5  0x006eb3de in RefCountCache::put (this=0x18051e0, 
> key=6912554662447498853, item=0x2b78aee04f00, size=16, 
> expiry_time=1475202356) at ./P_RefCountCache.h:462
> No locals.
> #6  0x006e2d8e in HostDBContinuation::dnsEvent (this=0x2b7938020f00, 
> event=600, e=0x2b78ac009440) at HostDB.cc:1422
> is_rr = false
> old_rr_data = 0x0
> first_record = 0x2b78ac0094f8
> m = 0x1
> failed = false
> old_r = {m_ptr = 0x0}
> af = 2 '\002'
> s_size = 16
> rrsize = 0
> allocSize = 16
> r = 0x2b78aee04f00
> old_info = { = { = {_vptr.ForceVFPTToTop 
> = 0x7f3630}, m_refcount = 0}, iobuffer_index = 0, 
>   key = 47797242059264, app = {allotment = {application1 = 5326300, 
> application2 = 0}, http_data = {http_version = 4, 
>   pipeline_max = 59, keepalive_timeout = 17, fail_count = 81, 
> unused1 = 0, last_failure = 0}, rr = {offset = 5326300}}, data = {
> ip = {sa = {sa_family = 54488, sa_data = 
> "^\000\000\000\000\000\020\034$\274x+\000"}, sin = {sin_family = 54488, 
> sin_port = 94, 
> sin_addr = {s_addr = 0}, sin_zero = "\020\034$\274x+\000"}, 
> sin6 = {sin6_family = 54488, sin6_port = 94, sin6_flowinfo = 0, 
> sin6_addr = {__in6_u = {__u6_addr8 = 
> "\020\034$\274x+\000\000\030\036$\274\375\b\000", __u6_addr16 = {7184, 48164, 
> 11128, 
>   0, 7704, 48164, 2301, 0}, __u6_addr32 = {3156483088, 
> 11128, 3156483608, 2301}}}, sin6_scope_id = 3156478176}}, 
> hostname_offset = 6214872, srv = {srv_offset = 54488, srv_weight 
> = 94, srv_priority = 0, srv_port = 0, key = 3156483088}}, 
>   hostname_offset = 11128, ip_timestamp = 2845989456, 
> ip_timeout_interval = 11128, is_srv = 0, reverse_dns = 0, round_robin = 1, 
>   round_robin_elt = 0}
> valid_records = 0
> tip = {_family = 2, _addr = {_ip4 = 540420056, _ip6 = {__in6_u = 
> {__u6_addr8 = "\330'6 x+\000\000\360L\020\250x+\000", 
> __u6_addr16 = {10200, 8246, 11128, 0, 19696, 43024, 11128, 
> 0}, __u6_addr32 = {540420056, 11128, 2819640560, 11128}}}, 
> _byte = "\330'6 x+\000\000\360L\020\250x+\000", _u32 = 
> {540420056, 11128, 2819640560, 11128}, _u64 = {47794936489944, 
>   47797215710448}}}
> ttl_seconds = 132
> aname = 0x2b7938021000 "fbmm1.zenfs.com"
> offset = 96
> thread = 0x2b78a8101010
> __func__ = "dnsEvent"
> #7  0x005145dc in Continuation::handleEvent (this=0x2b7938020f00, 
> event=600, data=0x2b78ac009440)
> at ../iocore/eventsystem/I_Continuation.h:153
> No locals.
> #8  0x006f681e in DNSEntry::postEvent (this=0x2b78f4028600) at 
> DNS.cc:1269
> __func__ = "postEvent"
> #9  0x005145dc in Continuation::handleEvent (this=0x2b78f4028600, 
> event=1, data=0x2aac954db040)
> at ../iocore/eventsystem/I_Continuation.h:153
> No locals.
> #10 0x007bc9be in EThread::process_event (this=0x2b78a8101010, 
> e=0x2aac954db040, calling_code=1) at UnixEThread.cc:143
> 

[jira] [Commented] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[Susan Hinrichs (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552505#comment-15552505
 ] 

Susan Hinrichs commented on TS-4916:


[~gancho] you might also look at this fix for TS-4813, which is now merged.  It 
rearranges some of the stream_count book keeping.  I haven't seen this crash 
again recently.  Though I am crashing pretty frequently due to TS-4915, so it 
could be that I'm just not running long enough. 

It looked like we had simultaneous threads manipulating the stream list.  DLL<> 
is not thread safe.

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> --- count=3 ---
> 

[jira] [Created] (TS-4941) Preserve pristine Host and URI for header_rewrite expansion

[Phillip Moore (JIRA)]

Phillip Moore created TS-4941:
-

 Summary: Preserve pristine Host and URI for header_rewrite 
expansion
 Key: TS-4941
 URL: https://issues.apache.org/jira/browse/TS-4941
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: Phillip Moore


It would be very handy to be able to access the pristine Host and URI for a 
request for substitutions in header_rewrite plugin. Right now the list of 
expandable variables does not include this. 

If we were able to use CLIENT-URL and CLIENT-HEADER as part of variable 
expansion and they were kept truly pristine regardless of hook context as the 
documentation implies  it would solve this as well. 



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

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[GitHub] trafficserver issue #1083: TS-4938: Avoid crashes due to NULL vc dereference...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/835/ 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-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 16:52
Start Date: 06/Oct/16 16:52
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[GitHub] trafficserver issue #1083: TS-4938: Avoid crashes due to NULL vc dereference...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/943/ 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 : clang-analyzer #2687

[jenkins]

See 

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 16:38
Start Date: 06/Oct/16 16:38
Worklog Time Spent: 10m 
  Work Description: GitHub user shinrich opened a pull request:

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

TS-4938: Avoid crashes due to NULL vc dereferences.

While debugging the fix for TS-4813, I saw a crash due to a 
ua_session->get_netvc() being null be being dereferenced anyway in 
HttpTransact.  In this PR I'm trying to be defensive in dealing with this.  
Actually there was a straight up correctness issue with the 
set_active/inactivity_timeout going through the ua_session->get_netvc() rather 
than ua_session.  The timeouts are handled differently for Http2 than for 
Http1, so we really need to pass through the ProxyClientTransaction object.

The other cases, are pulling local/remote address/port information.  
Eventually we should sink that into the ProxyClientTransaction layer too, but 
for this PR, I'm just doing the NULL checks.  Forward progress.

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

$ git pull https://github.com/shinrich/trafficserver ts-4938

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

https://github.com/apache/trafficserver/pull/1083.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 #1083


commit 6c4fc39874be53051497975ffc47c5102c623ba1
Author: Susan Hinrichs 
Date:   2016-10-06T16:20:08Z

TS-4938: Avoid crashes due to NULL vc dereferences.




Issue Time Tracking
---

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

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> 

[GitHub] trafficserver pull request #1083: TS-4938: Avoid crashes due to NULL vc dere...

[shinrich]

GitHub user shinrich opened a pull request:

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

TS-4938: Avoid crashes due to NULL vc dereferences.

While debugging the fix for TS-4813, I saw a crash due to a 
ua_session->get_netvc() being null be being dereferenced anyway in 
HttpTransact.  In this PR I'm trying to be defensive in dealing with this.  
Actually there was a straight up correctness issue with the 
set_active/inactivity_timeout going through the ua_session->get_netvc() rather 
than ua_session.  The timeouts are handled differently for Http2 than for 
Http1, so we really need to pass through the ProxyClientTransaction object.

The other cases, are pulling local/remote address/port information.  
Eventually we should sink that into the ProxyClientTransaction layer too, but 
for this PR, I'm just doing the NULL checks.  Forward progress.

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

$ git pull https://github.com/shinrich/trafficserver ts-4938

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

https://github.com/apache/trafficserver/pull/1083.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 #1083


commit 6c4fc39874be53051497975ffc47c5102c623ba1
Author: Susan Hinrichs 
Date:   2016-10-06T16:20:08Z

TS-4938: Avoid crashes due to NULL vc dereferences.




---
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 : centos_7-master » gcc,centos_7,release #2043

[jenkins]

See 

Jenkins build is back to normal : ubuntu_14_04-master » gcc,ubuntu_14_04,release #2270

[jenkins]

See 

[jira] [Work logged] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 16:17
Start Date: 06/Oct/16 16:17
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[jira] [Resolved] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[Leif Hedstrom (JIRA)]

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

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

> Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[GitHub] trafficserver pull request #1076: TS-4929: No loading of HostDB disk file if...

[zwoop]

Github user zwoop closed the pull request at:

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


---
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] [Commented] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552361#comment-15552361
 ] 

Leif Hedstrom commented on TS-4940:
---

[~jsime] I think this is a documentation issue, certain strings requires quotes 
when used as an operand like this. The solution in this case is to change this 
to

{code}
cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip "%"
{code}

> header_rewrite in 6.2.0 doesn't expand variables properly
> -
>
> Key: TS-4940
> URL: https://issues.apache.org/jira/browse/TS-4940
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Phillip Moore
>Assignee: Jon Sime
> Fix For: Docs
>
>
> We have a header_rewrite.config   configured to add some headers for original 
>  IP address of requestor.
> {code}
> cond %{SEND_REQUEST_HDR_HOOK}
> rm-header X-Box-Original-Ip
> add-header X-Box-Original-Ip %
> {code}
> In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
> and for the header we get a literal %.
> 6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
> 5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



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

[jira] [Updated] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4940:
--
Fix Version/s: Docs

> header_rewrite in 6.2.0 doesn't expand variables properly
> -
>
> Key: TS-4940
> URL: https://issues.apache.org/jira/browse/TS-4940
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Phillip Moore
> Fix For: Docs
>
>
> We have a header_rewrite.config   configured to add some headers for original 
>  IP address of requestor.
> {code}
> cond %{SEND_REQUEST_HDR_HOOK}
> rm-header X-Box-Original-Ip
> add-header X-Box-Original-Ip %
> {code}
> In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
> and for the header we get a literal %.
> 6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
> 5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



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

[jira] [Updated] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4940:
--
Assignee: Jon Sime

> header_rewrite in 6.2.0 doesn't expand variables properly
> -
>
> Key: TS-4940
> URL: https://issues.apache.org/jira/browse/TS-4940
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Phillip Moore
>Assignee: Jon Sime
> Fix For: Docs
>
>
> We have a header_rewrite.config   configured to add some headers for original 
>  IP address of requestor.
> {code}
> cond %{SEND_REQUEST_HDR_HOOK}
> rm-header X-Box-Original-Ip
> add-header X-Box-Original-Ip %
> {code}
> In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
> and for the header we get a literal %.
> 6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
> 5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



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

[jira] [Updated] (TS-4939) Diags doesn't print the tag name anymore

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4939:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Updated] (TS-4939) Diags doesn't print the tag name anymore

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4939:
---
Backport to Version:   (was: 7.0.0)

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Resolved] (TS-4939) Diags doesn't print the tag name anymore

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4939.

Resolution: Fixed

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Work logged] (TS-4939) Diags doesn't print the tag name anymore

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 16:04
Start Date: 06/Oct/16 16:04
Worklog Time Spent: 10m 
  Work Description: Github user bryancall closed the pull request at:

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


Issue Time Tracking
---

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

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[jira] [Work logged] (TS-4939) Diags doesn't print the tag name anymore

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 06/Oct/16 16:04
Start Date: 06/Oct/16 16:04
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1082
  
  - code looks good and tested!


Issue Time Tracking
---

Worklog Id: (was: 30227)
Time Spent: 40m  (was: 0.5h)

> Diags doesn't print the tag name anymore
> 
>
> Key: TS-4939
> URL: https://issues.apache.org/jira/browse/TS-4939
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Diags used to print the tag name in the output before.  It looks like it was 
> broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a.



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

[GitHub] trafficserver pull request #1082: TS-4939: Print the debug tag in diagnostic...

[bryancall]

Github user bryancall closed the pull request at:

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


---
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 #1082: TS-4939: Print the debug tag in diagnostic messag...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1082
  
👍  - code looks good and tested!


---
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] [Commented] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552216#comment-15552216
 ] 

Leif Hedstrom commented on TS-4940:
---

I think the quotes around "special" characters are required now.

> header_rewrite in 6.2.0 doesn't expand variables properly
> -
>
> Key: TS-4940
> URL: https://issues.apache.org/jira/browse/TS-4940
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Phillip Moore
>
> We have a header_rewrite.config   configured to add some headers for original 
>  IP address of requestor.
> {code}
> cond %{SEND_REQUEST_HDR_HOOK}
> rm-header X-Box-Original-Ip
> add-header X-Box-Original-Ip %
> {code}
> In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
> and for the header we get a literal %.
> 6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
> 5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



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

[jira] [Updated] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly

[James Peach (JIRA)]

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

James Peach updated TS-4940:

Description: 
We have a header_rewrite.config   configured to add some headers for original  
IP address of requestor.

{noformat}
cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip %
{noformat}

In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
and for the header we get a literal %.

6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



  was:
We have a header_rewrite.config   configured to add some headers for original  
IP address of requestor.

cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip %

In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
and for the header we get a literal %.

6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50




> header_rewrite in 6.2.0 doesn't expand variables properly
> -
>
> Key: TS-4940
> URL: https://issues.apache.org/jira/browse/TS-4940
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Phillip Moore
>
> We have a header_rewrite.config   configured to add some headers for original 
>  IP address of requestor.
> {noformat}
> cond %{SEND_REQUEST_HDR_HOOK}
> rm-header X-Box-Original-Ip
> add-header X-Box-Original-Ip %
> {noformat}
> In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
> and for the header we get a literal %.
> 6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
> 5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



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

[jira] [Updated] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly

[Phillip Moore (JIRA)]

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

Phillip Moore updated TS-4940:
--
Description: 
We have a header_rewrite.config   configured to add some headers for original  
IP address of requestor.

{code}
cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip %
{code}

In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
and for the header we get a literal %.

6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



  was:
We have a header_rewrite.config   configured to add some headers for original  
IP address of requestor.

{noformat}
cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip %
{noformat}

In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
and for the header we get a literal %.

6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50




> header_rewrite in 6.2.0 doesn't expand variables properly
> -
>
> Key: TS-4940
> URL: https://issues.apache.org/jira/browse/TS-4940
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Phillip Moore
>
> We have a header_rewrite.config   configured to add some headers for original 
>  IP address of requestor.
> {code}
> cond %{SEND_REQUEST_HDR_HOOK}
> rm-header X-Box-Original-Ip
> add-header X-Box-Original-Ip %
> {code}
> In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
> and for the header we get a literal %.
> 6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
> 5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50



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

[jira] [Created] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly

[Phillip Moore (JIRA)]

Phillip Moore created TS-4940:
-

 Summary: header_rewrite in 6.2.0 doesn't expand variables properly
 Key: TS-4940
 URL: https://issues.apache.org/jira/browse/TS-4940
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: Phillip Moore


We have a header_rewrite.config   configured to add some headers for original  
IP address of requestor.

cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip %

In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly 
and for the header we get a literal %.

6.2.0:   HTTP_X_BOX_ORIGINAL_IP=%
5.1.2:   HTTP_X_BOX_ORIGINAL_IP=10.3.18.50





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