[jira] [Work logged] (TS-4808) General diagnostics cleanup.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> General diagnostics cleanup.
> 
>
> Key: TS-4808
> URL: https://issues.apache.org/jira/browse/TS-4808
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I started by noticing that {{RecDebug}} didn't emit the source location, and 
> ended up shifting all the {{Diags}} code over to using {{SourceLocation}} and 
> removing duplicated code in the diagnostic logging systems.



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

[jira] [Work logged] (TS-4808) General diagnostics cleanup.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> General diagnostics cleanup.
> 
>
> Key: TS-4808
> URL: https://issues.apache.org/jira/browse/TS-4808
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I started by noticing that {{RecDebug}} didn't emit the source location, and 
> ended up shifting all the {{Diags}} code over to using {{SourceLocation}} and 
> removing duplicated code in the diagnostic logging systems.



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

[GitHub] trafficserver issue #959: TS-4808: General diagnostics cleanup.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/959
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/676/ 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 #872: TS-4735: Fix race condition in traffic_server star...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
The 10k is an arbitrary number chosen in 
[TS-4161](https://issues.apache.org/jira/browse/TS-4161).


---
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-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/872
  
The 10k is an arbitrary number chosen in 
[TS-4161](https://issues.apache.org/jira/browse/TS-4161).


Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[jira] [Work logged] (TS-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 05:13
Start Date: 02/Sep/16 05:13
Worklog Time Spent: 10m 
  Work Description: Github user kshri23 commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
James, that is a good idea. I am not sure but I think it should be okay to 
do so. I will need to dig in  a bit though to understand why this value was 
fixed unless anyone recollects we chose 10k?


Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[GitHub] trafficserver issue #872: TS-4735: Fix race condition in traffic_server star...

[kshri23]

Github user kshri23 commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
James, that is a good idea. I am not sure but I think it should be okay to 
do so. I will need to dig in  a bit though to understand why this value was 
fixed unless anyone recollects we chose 10k?


---
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-4808) General diagnostics cleanup.

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4808: General diagnostics cleanup.

  - Clean up the Diags class to remove code duplication.
  - Switch all the diagnostic formatters over to using SourceLocation.
  - Remove useless mgmt_log functions which sometimes take stderr paramets.
  - Remove TSDiags() because it is awkward to pass a SourceLocation down.

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

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

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

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


commit 57e1374006c6b2bfe6aea0c9a8ca01f2af8875b1
Author: James Peach 
Date:   2016-09-02T05:09:50Z

TS-4808: General diagnostics cleanup.

  - Clean up the Diags class to remove code duplication.
  - Switch all the diagnostic formatters over to using SourceLocation.
  - Remove useless mgmt_log functions which sometimes take stderr paramets.
  - Remove TSDiags() because it is awkward to pass a SourceLocation down.




Issue Time Tracking
---

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

> General diagnostics cleanup.
> 
>
> Key: TS-4808
> URL: https://issues.apache.org/jira/browse/TS-4808
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Reporter: James Peach
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I started by noticing that {{RecDebug}} didn't emit the source location, and 
> ended up shifting all the {{Diags}} code over to using {{SourceLocation}} and 
> removing duplicated code in the diagnostic logging systems.



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

[GitHub] trafficserver pull request #959: TS-4808: General diagnostics cleanup.

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4808: General diagnostics cleanup.

  - Clean up the Diags class to remove code duplication.
  - Switch all the diagnostic formatters over to using SourceLocation.
  - Remove useless mgmt_log functions which sometimes take stderr paramets.
  - Remove TSDiags() because it is awkward to pass a SourceLocation down.

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

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

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

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


commit 57e1374006c6b2bfe6aea0c9a8ca01f2af8875b1
Author: James Peach 
Date:   2016-09-02T05:09:50Z

TS-4808: General diagnostics cleanup.

  - Clean up the Diags class to remove code duplication.
  - Switch all the diagnostic formatters over to using SourceLocation.
  - Remove useless mgmt_log functions which sometimes take stderr paramets.
  - Remove TSDiags() because it is awkward to pass a SourceLocation down.




---
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-4808) General diagnostics cleanup.

[James Peach (JIRA)]

James Peach created TS-4808:
---

 Summary: General diagnostics cleanup.
 Key: TS-4808
 URL: https://issues.apache.org/jira/browse/TS-4808
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, Logging
Reporter: James Peach


I started by noticing that {{RecDebug}} didn't emit the source location, and 
ended up shifting all the {{Diags}} code over to using {{SourceLocation}} and 
removing duplicated code in the diagnostic logging systems.



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

[jira] [Created] (TS-4807) Use standard signal handling in traffic_manager.

[James Peach (JIRA)]

James Peach created TS-4807:
---

 Summary: Use standard signal handling in traffic_manager.
 Key: TS-4807
 URL: https://issues.apache.org/jira/browse/TS-4807
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, Manager
Reporter: James Peach


{{traffic_manager}} does some ancient cruft stuff handling signals. We can 
replace most of it with the utility functions in {{ts/lib/signals.h}}.



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

[GitHub] trafficserver pull request #951: TS-4797: Allow backslash-escape in header_r...

[masaori335]

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

https://github.com/apache/trafficserver/pull/951#discussion_r77287760
  
--- Diff: plugins/header_rewrite/parser.cc ---
@@ -50,6 +52,12 @@ Parser::Parser(const std::string ) : _cond(false), 
_empty(false)
 _tokens.push_back(std::string(1, line[i]));
   }
   continue; /* always eat whitespace */
+} else if (line[i] == '\\') {
+  // erase a backslash in quoted-string
+  if (inquote && extracting_token) {
--- End diff --

My commit message might be not suitable. What I want to fix is we can't use 
**double quote** inside of quoted string.

We can make this more general, but it makes header_rewrite rules and parser 
code more complicated.
Do you have any specific use cases to escape something outside of quoted 
string?


---
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-4797) Backslash-escape is not allowed in rewriting rules

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 03:15
Start Date: 02/Sep/16 03:15
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/951#discussion_r77287760
  
--- Diff: plugins/header_rewrite/parser.cc ---
@@ -50,6 +52,12 @@ Parser::Parser(const std::string ) : _cond(false), 
_empty(false)
 _tokens.push_back(std::string(1, line[i]));
   }
   continue; /* always eat whitespace */
+} else if (line[i] == '\\') {
+  // erase a backslash in quoted-string
+  if (inquote && extracting_token) {
--- End diff --

My commit message might be not suitable. What I want to fix is we can't use 
**double quote** inside of quoted string.

We can make this more general, but it makes header_rewrite rules and parser 
code more complicated.
Do you have any specific use cases to escape something outside of quoted 
string?


Issue Time Tracking
---

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

> Backslash-escape is not allowed in rewriting rules
> --
>
> Key: TS-4797
> URL: https://issues.apache.org/jira/browse/TS-4797
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I noticed that backslash-escape in quoted-string is not allowed in 
> header-rewrite plugin rules. IIRC, this is allowed in 5.3.x.
> e.g.
> {noformat}
> cond %{SEND_RESPONSE_HDR_HOOK}
> add-header Public-Key-Pins 
> "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]
> {noformat}
> I got below error
> {noformat}
> 20160830.16h19m34s [header_rewrite] malformed line "add-header 
> Public-Key-Pins "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]" ignoring...
> {noformat}



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

[GitHub] trafficserver issue #893: TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.c...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/571/ 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-4581) CID 1356973 dead code in proxy/hdrs/HTTP.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> CID 1356973 dead code in proxy/hdrs/HTTP.cc
> ---
>
> Key: TS-4581
> URL: https://issues.apache.org/jira/browse/TS-4581
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> 1069
>   notnull: At condition url_start, the value of url_start cannot be NULL.
>   dead_error_condition: The condition !url_start cannot be true.
>   notnull: At condition url_end, the value of url_end cannot be NULL.
>   dead_error_condition: The condition !url_end cannot be true.
> 1070if (!url_start || !url_end)
>   
> CID 1356973 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return PARSE_ERROR;.
> 1071  return PARSE_ERROR;



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

[jira] [Work logged] (TS-4796) ATS not closing origin connections on first RST from client

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 02:09
Start Date: 02/Sep/16 02:09
Worklog Time Spent: 10m 
  Work Description: Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
EVENTIO_ERROR  means EPOLLHUP | EPOLLERR | EPOLLPRI.

EPOLLPRI means OOB or TCP URG is set. You will always receive EPOLLPRI with 
EPOLLIN.
To EPOLLPRI, we need handle READ first and ignore EPOLLPRI, this is what 
NetHandler does.

EPOLLHUP & EPOLLRDHUP
reference : 
http://stackoverflow.com/questions/8707458/epoll-and-remote-1-way-shutdown
```
A socket listening for epoll events will typically receive an EPOLLRDHUP 
(in addition to EPOLLIN) event flag upon the remote peer calling close or 
shutdown(SHUT_WR). This does not neccessarily mean the socket is dead. 
Subsequent calls to recv() will return any unread data on the socket and 
eventually "0" will be returned to indicate EOF. It may even be possible to 
send data back if the remote peer only did a half-close of its socket.

The one notable exception is if the remote peer is using the SO_LINGER 
option enabled on its socket with a linger value of "0". The result of closing 
such a socket may result in a TCP RST getting sent instead of a FIN. From what 
I've read, a connection reset event will generate either a EPOLLHUP or 
EPOLLERR. (I haven't had time to confirm, but it makes sense).

There is some documentation to suggest there are older Linux 
implementations that don't support EPOLLRDHUP, as such EPOLLHUP gets generated 
instead.

And for what it is worth, in my particular case, I found that it is not too 
interesting to have code that special cases EPOLLHUP or EPOLLRDHUP events. 
Instead, just treat these events the same as EPOLLIN/EPOLLOUT and call recv() 
(or send() as appropriate). But pay close attention to return codes returned 
back from recv() and send().
```

EPOLLERR means the possible non-fatal errors on socket fd such as EAGAIN, 
EINTR, EWOULDBLOCK and fatal errors.

When you receive EPLLERR, it means an error of socketfd and also there may 
be data before this error. Therefore we should call read() and write() to 
figure out the actual meanning of this error

Currently, NetHandler try to perform read() & write() on the socket fd 
first.
We will get non-fatal errors or fatal erros from read() or write().
if it is non-fatal error, just put socket fd into wait list.
if it is fatal error, signal SM to close socket fd.
e.g.
There is a Fatal ERROR if EPIPE is returned from write().
If "0" is returned from read() there is EOF.

So the currently implement of NetHandler is enough to handle all of this 
and doesn't need to change.


Issue Time Tracking
---

Worklog Id: (was: 27886)
Time Spent: 2h 50m  (was: 2h 40m)

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] 

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
EVENTIO_ERROR  means EPOLLHUP | EPOLLERR | EPOLLPRI.

EPOLLPRI means OOB or TCP URG is set. You will always receive EPOLLPRI with 
EPOLLIN.
To EPOLLPRI, we need handle READ first and ignore EPOLLPRI, this is what 
NetHandler does.

EPOLLHUP & EPOLLRDHUP
reference : 
http://stackoverflow.com/questions/8707458/epoll-and-remote-1-way-shutdown
```
A socket listening for epoll events will typically receive an EPOLLRDHUP 
(in addition to EPOLLIN) event flag upon the remote peer calling close or 
shutdown(SHUT_WR). This does not neccessarily mean the socket is dead. 
Subsequent calls to recv() will return any unread data on the socket and 
eventually "0" will be returned to indicate EOF. It may even be possible to 
send data back if the remote peer only did a half-close of its socket.

The one notable exception is if the remote peer is using the SO_LINGER 
option enabled on its socket with a linger value of "0". The result of closing 
such a socket may result in a TCP RST getting sent instead of a FIN. From what 
I've read, a connection reset event will generate either a EPOLLHUP or 
EPOLLERR. (I haven't had time to confirm, but it makes sense).

There is some documentation to suggest there are older Linux 
implementations that don't support EPOLLRDHUP, as such EPOLLHUP gets generated 
instead.

And for what it is worth, in my particular case, I found that it is not too 
interesting to have code that special cases EPOLLHUP or EPOLLRDHUP events. 
Instead, just treat these events the same as EPOLLIN/EPOLLOUT and call recv() 
(or send() as appropriate). But pay close attention to return codes returned 
back from recv() and send().
```

EPOLLERR means the possible non-fatal errors on socket fd such as EAGAIN, 
EINTR, EWOULDBLOCK and fatal errors.

When you receive EPLLERR, it means an error of socketfd and also there may 
be data before this error. Therefore we should call read() and write() to 
figure out the actual meanning of this error

Currently, NetHandler try to perform read() & write() on the socket fd 
first.
We will get non-fatal errors or fatal erros from read() or write().
if it is non-fatal error, just put socket fd into wait list.
if it is fatal error, signal SM to close socket fd.
e.g.
There is a Fatal ERROR if EPIPE is returned from write().
If "0" is returned from read() there is EOF.

So the currently implement of NetHandler is enough to handle all of this 
and doesn't need to change.


---
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 #893: TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.c...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/675/ 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-4581) CID 1356973 dead code in proxy/hdrs/HTTP.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> CID 1356973 dead code in proxy/hdrs/HTTP.cc
> ---
>
> Key: TS-4581
> URL: https://issues.apache.org/jira/browse/TS-4581
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> 1069
>   notnull: At condition url_start, the value of url_start cannot be NULL.
>   dead_error_condition: The condition !url_start cannot be true.
>   notnull: At condition url_end, the value of url_end cannot be NULL.
>   dead_error_condition: The condition !url_end cannot be true.
> 1070if (!url_start || !url_end)
>   
> CID 1356973 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return PARSE_ERROR;.
> 1071  return PARSE_ERROR;



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

[jira] [Work logged] (TS-4581) CID 1356973 dead code in proxy/hdrs/HTTP.cc

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 01:58
Start Date: 02/Sep/16 01:58
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
[approve ci]


Issue Time Tracking
---

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

> CID 1356973 dead code in proxy/hdrs/HTTP.cc
> ---
>
> Key: TS-4581
> URL: https://issues.apache.org/jira/browse/TS-4581
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> 1069
>   notnull: At condition url_start, the value of url_start cannot be NULL.
>   dead_error_condition: The condition !url_start cannot be true.
>   notnull: At condition url_end, the value of url_end cannot be NULL.
>   dead_error_condition: The condition !url_end cannot be true.
> 1070if (!url_start || !url_end)
>   
> CID 1356973 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return PARSE_ERROR;.
> 1071  return PARSE_ERROR;



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

[GitHub] trafficserver issue #893: TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.c...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
[approve ci]


---
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-4581) CID 1356973 dead code in proxy/hdrs/HTTP.cc

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 01:57
Start Date: 02/Sep/16 01:57
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
I'm not 100% certain that Coverity will think this is enough, but lets try. 
@jpeach ok with this ?


Issue Time Tracking
---

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

> CID 1356973 dead code in proxy/hdrs/HTTP.cc
> ---
>
> Key: TS-4581
> URL: https://issues.apache.org/jira/browse/TS-4581
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> 1069
>   notnull: At condition url_start, the value of url_start cannot be NULL.
>   dead_error_condition: The condition !url_start cannot be true.
>   notnull: At condition url_end, the value of url_end cannot be NULL.
>   dead_error_condition: The condition !url_end cannot be true.
> 1070if (!url_start || !url_end)
>   
> CID 1356973 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return PARSE_ERROR;.
> 1071  return PARSE_ERROR;



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

[GitHub] trafficserver issue #893: TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.c...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
I'm not 100% certain that Coverity will think this is enough, but lets try. 
@jpeach ok with this ?


---
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-4798) Crashing when using balancer plugin

[Gandhimathi Velusamy (JIRA)]

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

Gandhimathi Velusamy commented on TS-4798:
--

Please, find my stack trace:
traffic_server: Segmentation fault (Address not mapped to object [0x88])
traffic_server - STACK TRACE: 
bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ad02e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fe54840c330]
bin/traffic_server(_ZNK22ProxyClientTransaction9get_netvcEv+0xc)[0x4f122c]
bin/traffic_server(_ZN6HttpSM12update_statsEv+0x322)[0x5a1282]
bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x380)[0x5b3e60]
bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x108)[0x5b49f8]
bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x19d)[0x5f125d]
bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x11f0)[0x749c70]
bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x29c)[0x73b6dc]
bin/traffic_server(_ZN7EThread7executeEv+0x9c2)[0x76d442]
bin/traffic_server[0x76c04a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe548404184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe54770d37d]

> Crashing when using balancer plugin
> ---
>
> Key: TS-4798
> URL: https://issues.apache.org/jira/browse/TS-4798
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Gandhimathi Velusamy
> Attachments: Steps_TrafficServer_balancer .pdf
>
>
> {noformat}
> Process:sudo [24280]
> File:   /usr/bin/sudo
> Version:Traffic Server 7.0.0
> System Version: Linux x86_64 #111-Ubuntu SMP Fri Nov 6 18:17:06 UTC 2015 
> 3.13.0-68-generic
> Date:   Tue, 30 Aug 2016 14:42:24 -0400
> No target signal information
> No target CPU registers
> Unable to retrieve backtrace: [5] Error establishing socket connection.
> Process Status:
> Name: sudo
> State:S (sleeping)
> Tgid: 24280
> Ngid: 0
> Pid:  24280
> PPid: 25297
> TracerPid:0
> Uid:  0   0   0   0
> Gid:  1000100010001000
> FDSize:   256
> Groups:   1000 
> VmPeak:  64980 kB
> VmSize:  64944 kB
> VmLck:   0 kB
> VmPin:   0 kB
> VmHWM:2060 kB
> VmRSS:2060 kB
> VmData:508 kB
> VmStk: 136 kB
> VmExe: 144 kB
> VmLib:3784 kB
> VmPTE: 144 kB
> VmSwap:  0 kB
> Threads:  1
> SigQ: 0/47585
> SigPnd:   
> ShdPnd:   
> SigBlk:   
> SigIgn:   
> SigCgt:   0001800b7a07
> CapInh:   
> CapPrm:   001f
> CapEff:   001f
> CapBnd:   001f
> Seccomp:  0
> Cpus_allowed: 3
> Cpus_allowed_list:0-1
> Mems_allowed: ,0001
> Mems_allowed_list:0
> voluntary_ctxt_switches:  2
> nonvoluntary_ctxt_switches:   4
> Memory Regions:
> 7f588b6bd000-7f588b6d6000 r-xp  fd:00 31852  
> /lib/x86_64-linux-gnu/libpthread-2.19.so
> 7f588b6d6000-7f588b8d5000 ---p 00019000 fd:00 31852  
> /lib/x86_64-linux-gnu/libpthread-2.19.so
> 7f588b8d5000-7f588b8d6000 r--p 00018000 fd:00 31852  
> /lib/x86_64-linux-gnu/libpthread-2.19.so
> 7f588b8d6000-7f588b8d7000 rw-p 00019000 fd:00 31852  
> /lib/x86_64-linux-gnu/libpthread-2.19.so
> 7f588b8d7000-7f588b8db000 rw-p  00:00 0 
> 7f588b8db000-7f588b8e2000 r-xp  fd:00 31860  
> /lib/x86_64-linux-gnu/librt-2.19.so
> 7f588b8e2000-7f588bae1000 ---p 7000 fd:00 31860  
> /lib/x86_64-linux-gnu/librt-2.19.so
> 7f588bae1000-7f588bae2000 r--p 6000 fd:00 31860  
> /lib/x86_64-linux-gnu/librt-2.19.so
> 7f588bae2000-7f588bae3000 rw-p 7000 fd:00 31860  
> /lib/x86_64-linux-gnu/librt-2.19.so
> 7f588bae3000-7f588bae6000 r-xp  fd:00 31726  
> /lib/x86_64-linux-gnu/libpam_misc.so.0.82.0
> 7f588bae6000-7f588bce5000 ---p 3000 fd:00 31726  
> /lib/x86_64-linux-gnu/libpam_misc.so.0.82.0
> 7f588bce5000-7f588bce6000 r--p 2000 fd:00 31726  
> /lib/x86_64-linux-gnu/libpam_misc.so.0.82.0
> 7f588bce6000-7f588bce7000 rw-p 3000 fd:00 31726  
> /lib/x86_64-linux-gnu/libpam_misc.so.0.82.0
> 7f588bce7000-7f588bd2b000 r-xp  fd:00 31496  
> /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6
> 7f588bd2b000-7f588bf2a000 ---p 00044000 fd:00 31496  
> /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6
> 7f588bf2a000-7f588bf2b000 r--p 00043000 fd:00 31496  
> /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6
> 7f588bf2b000-7f588bf2c000 rw-p 

[GitHub] trafficserver issue #958: TS-4449 Better errors and debug output

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/958
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/570/ 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-4449) header_rewrite: Improve TSDebug() statements

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_rewrite: Improve TSDebug() statements
> 
>
> Key: TS-4449
> URL: https://issues.apache.org/jira/browse/TS-4449
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Right now, it can be difficult at times to understand why header_rewrite 
> isn't behaving as you'd expect. There are a number of places where we can 
> improve TSDebug().
> Also, I'm going to do a code cleanup here, to make the code more inline with 
> our current best practices (e.g. use if () { } consistently).



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

[jira] [Work logged] (TS-4449) header_rewrite: Improve TSDebug() statements

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 01:44
Start Date: 02/Sep/16 01:44
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> header_rewrite: Improve TSDebug() statements
> 
>
> Key: TS-4449
> URL: https://issues.apache.org/jira/browse/TS-4449
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Right now, it can be difficult at times to understand why header_rewrite 
> isn't behaving as you'd expect. There are a number of places where we can 
> improve TSDebug().
> Also, I'm going to do a code cleanup here, to make the code more inline with 
> our current best practices (e.g. use if () { } consistently).



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

[GitHub] trafficserver issue #958: TS-4449 Better errors and debug output

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/958
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/674/ 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-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 01:37
Start Date: 02/Sep/16 01:37
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
This is failing on Linux because of clang-format. Please run "make 
clang-format" and push again.


Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[GitHub] trafficserver issue #872: TS-4735: Fix race condition in traffic_server star...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
This is failing on Linux because of clang-format. Please run "make 
clang-format" and push again.


---
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-4449) header_rewrite: Improve TSDebug() statements

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4449:
--
Backport to Version: 6.2.1

> header_rewrite: Improve TSDebug() statements
> 
>
> Key: TS-4449
> URL: https://issues.apache.org/jira/browse/TS-4449
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Right now, it can be difficult at times to understand why header_rewrite 
> isn't behaving as you'd expect. There are a number of places where we can 
> improve TSDebug().
> Also, I'm going to do a code cleanup here, to make the code more inline with 
> our current best practices (e.g. use if () { } consistently).



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

[jira] [Work logged] (TS-4449) header_rewrite: Improve TSDebug() statements

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 01:35
Start Date: 02/Sep/16 01:35
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4449 Better errors and debug output

This does a few things:

   1. Better error reports when parsing a config file
   2. Better diagnostics when debugging expressions

I also added an example to the docs, for a common use case that
turns out to be non-obvious.

(cherry picked from commit b905a52a4a7a0a3d05966bc1a74ee6407cf94c39)

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

$ git pull https://github.com/zwoop/trafficserver TS-4449-6.2.x

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

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


commit 2345b0460bdba992fdfa193c2b35609c58cd4ed8
Author: Leif Hedstrom 
Date:   2016-05-17T19:12:19Z

TS-4449 Better errors and debug output

This does a few things:

   1. Better error reports when parsing a config file
   2. Better diagnostics when debugging expressions

I also added an example to the docs, for a common use case that
turns out to be non-obvious.

(cherry picked from commit b905a52a4a7a0a3d05966bc1a74ee6407cf94c39)




Issue Time Tracking
---

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

> header_rewrite: Improve TSDebug() statements
> 
>
> Key: TS-4449
> URL: https://issues.apache.org/jira/browse/TS-4449
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Right now, it can be difficult at times to understand why header_rewrite 
> isn't behaving as you'd expect. There are a number of places where we can 
> improve TSDebug().
> Also, I'm going to do a code cleanup here, to make the code more inline with 
> our current best practices (e.g. use if () { } consistently).



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

[GitHub] trafficserver pull request #958: TS-4449 Better errors and debug output

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4449 Better errors and debug output

This does a few things:

   1. Better error reports when parsing a config file
   2. Better diagnostics when debugging expressions

I also added an example to the docs, for a common use case that
turns out to be non-obvious.

(cherry picked from commit b905a52a4a7a0a3d05966bc1a74ee6407cf94c39)

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

$ git pull https://github.com/zwoop/trafficserver TS-4449-6.2.x

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

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


commit 2345b0460bdba992fdfa193c2b35609c58cd4ed8
Author: Leif Hedstrom 
Date:   2016-05-17T19:12:19Z

TS-4449 Better errors and debug output

This does a few things:

   1. Better error reports when parsing a config file
   2. Better diagnostics when debugging expressions

I also added an example to the docs, for a common use case that
turns out to be non-obvious.

(cherry picked from commit b905a52a4a7a0a3d05966bc1a74ee6407cf94c39)




---
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-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 00:36
Start Date: 02/Sep/16 00:36
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[GitHub] trafficserver issue #872: TS-4735: Fix race condition in traffic_server star...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/673/ 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-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 00:28
Start Date: 02/Sep/16 00:28
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[jira] [Work logged] (TS-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 00:27
Start Date: 02/Sep/16 00:27
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
@kshri23 I dig into the startup sequence a bit more and I'm now convinced 
that this is a reasonable approach. What do you think about just changing 
``MAX_MSGS_IN_A_ROW`` to something sanely small (like 10)?

@kshri23 You need to run ``make -j clang-format``.


Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[GitHub] trafficserver issue #872: TS-4735: Fix race condition in traffic_server star...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/569/ 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 #872: TS-4735: Fix race condition in traffic_server star...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
@kshri23 I dig into the startup sequence a bit more and I'm now convinced 
that this is a reasonable approach. What do you think about just changing 
``MAX_MSGS_IN_A_ROW`` to something sanely small (like 10)?

@kshri23 You need to run ``make -j clang-format``.


---
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-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[GitHub] trafficserver issue #872: TS-4735: Fix race condition in traffic_server star...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/568/ 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-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 02/Sep/16 00:22
Start Date: 02/Sep/16 00:22
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
[approve ci]


Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[GitHub] trafficserver issue #872: TS-4735: Fix race condition in traffic_server star...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
[approve ci]


---
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-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[GitHub] trafficserver issue #957: TS-4801 Avoids marking parent down unless CONNECTI...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/567/ 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] [Resolved] (TS-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[Leif Hedstrom (JIRA)]

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

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

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



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

[jira] [Work logged] (TS-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 23:22
Start Date: 01/Sep/16 23:22
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



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

[jira] [Work logged] (TS-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 23:21
Start Date: 01/Sep/16 23:21
Worklog Time Spent: 10m 
  Work Description: Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
looks good +1


Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[GitHub] trafficserver pull request #953: TS-4402: Fixes some config "Int" types to "...

[zwoop]

Github user zwoop closed the pull request at:

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


---
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 #957: TS-4801 Avoids marking parent down unless CONNECTI...

[jrushford]

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
looks good +1


---
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-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[jira] [Work logged] (TS-4581) CID 1356973 dead code in proxy/hdrs/HTTP.cc

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 23:18
Start Date: 01/Sep/16 23:18
Worklog Time Spent: 10m 
  Work Description: Github user ngara commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
ok, conflicts resolved again


Issue Time Tracking
---

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

> CID 1356973 dead code in proxy/hdrs/HTTP.cc
> ---
>
> Key: TS-4581
> URL: https://issues.apache.org/jira/browse/TS-4581
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> 1069
>   notnull: At condition url_start, the value of url_start cannot be NULL.
>   dead_error_condition: The condition !url_start cannot be true.
>   notnull: At condition url_end, the value of url_end cannot be NULL.
>   dead_error_condition: The condition !url_end cannot be true.
> 1070if (!url_start || !url_end)
>   
> CID 1356973 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return PARSE_ERROR;.
> 1071  return PARSE_ERROR;



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

[GitHub] trafficserver issue #957: TS-4801 Avoids marking parent down unless CONNECTI...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/672/ 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 #893: TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.c...

[ngara]

Github user ngara commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
ok, conflicts resolved again


---
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-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



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

[GitHub] trafficserver issue #953: TS-4402 Fixes some config "Int" types to "Byte" ty...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/953
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/566/ 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-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[jira] [Work logged] (TS-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/957
  
Gah, FreeBSD is so finicky ... [approve ci]


Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[GitHub] trafficserver issue #957: TS-4801 Avoids marking parent down unless CONNECTI...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/565/ 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 #953: TS-4402 Fixes some config "Int" types to "Byte" ty...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/953
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/671/ 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-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



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

[GitHub] trafficserver issue #957: TS-4801 Avoids marking parent down unless CONNECTI...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
Gah, FreeBSD is so finicky ... [approve ci]


---
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-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[GitHub] trafficserver issue #957: TS-4801 Avoids marking parent down unless CONNECTI...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/670/ 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-4803) Remove proxy.config.dns.url_expansions

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:59
Start Date: 01/Sep/16 22:59
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Remove proxy.config.dns.url_expansions
> --
>
> Key: TS-4803
> URL: https://issues.apache.org/jira/browse/TS-4803
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, DNS
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> This is similar to TS-4725, so I think we should nuke this too.



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

[GitHub] trafficserver issue #950: TS-4803 Removes the config/support for proxy.confi...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/950
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/564/ 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-4803) Remove proxy.config.dns.url_expansions

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove proxy.config.dns.url_expansions
> --
>
> Key: TS-4803
> URL: https://issues.apache.org/jira/browse/TS-4803
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, DNS
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is similar to TS-4725, so I think we should nuke this too.



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

[GitHub] trafficserver issue #950: TS-4803 Removes the config/support for proxy.confi...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/950
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/669/ 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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:53
Start Date: 01/Sep/16 22:53
Worklog Time Spent: 10m 
  Work Description: Github user pbchou commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@zwoop @jrushford -- I pushed another commit which removes the use of the 
MIME header. It adds pointers to the HttpTransact::State's 
cache_info.lookup_url and cache_info.parent_selection_url variables into the 
HttpRequestHeader data structure. It looks like somebody used a similar 
approach with the api_info variable in HttpRequestHeader previously. I went 
ahead and included adding look_url to help with TS-4025 mentioned above.


Issue Time Tracking
---

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

> Parent Consistent Hash Selection - add fname and maxdirs options.
> -
>
> Key: TS-4707
> URL: https://issues.apache.org/jira/browse/TS-4707
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Peter Chou
>Assignee: Peter Chou
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> This enhancement adds two options, "fname" and "maxdirs", which can be used 
> to exclude the file-name and some of the directories in the path. The 
> remaining portions of the path are then used as part of the hash computation 
> for selecting among multiple parent caches.
> For our usage, it was desirable from an operational perspective to direct all 
> components of particular sub-tree to a single parent cache (to simplify 
> trouble-shooting, pre-loading, etc.). This can be achieved by excluding the 
> query-string, file-name, and right-most portions of the path from the hash 
> computation.



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

[GitHub] trafficserver issue #834: TS-4707 : Parent Consistent Hash Selection - add f...

[pbchou]

Github user pbchou commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@zwoop @jrushford -- I pushed another commit which removes the use of the 
MIME header. It adds pointers to the HttpTransact::State's 
cache_info.lookup_url and cache_info.parent_selection_url variables into the 
HttpRequestHeader data structure. It looks like somebody used a similar 
approach with the api_info variable in HttpRequestHeader previously. I went 
ahead and included adding look_url to help with TS-4025 mentioned above.


---
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 #957: TS-4801 Avoids marking parent down unless CONNECTI...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/563/ 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-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[jira] [Work logged] (TS-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:29
Start Date: 01/Sep/16 22:29
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[GitHub] trafficserver issue #957: TS-4801 Avoids marking parent down unless CONNECTI...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/957
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/668/ 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-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:28
Start Date: 01/Sep/16 22:28
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/953
  
Yep the ```:```.


Issue Time Tracking
---

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

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



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

[GitHub] trafficserver issue #953: TS-4402 Fixes some config "Int" types to "Byte" ty...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/953
  
Yep the ```:```.


---
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,debug #1944

[jenkins]

See 

[jira] [Work logged] (TS-4581) CID 1356973 dead code in proxy/hdrs/HTTP.cc

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:25
Start Date: 01/Sep/16 22:25
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
Hmmm, still seeing branch merge conflicts :-/


Issue Time Tracking
---

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

> CID 1356973 dead code in proxy/hdrs/HTTP.cc
> ---
>
> Key: TS-4581
> URL: https://issues.apache.org/jira/browse/TS-4581
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> 1069
>   notnull: At condition url_start, the value of url_start cannot be NULL.
>   dead_error_condition: The condition !url_start cannot be true.
>   notnull: At condition url_end, the value of url_end cannot be NULL.
>   dead_error_condition: The condition !url_end cannot be true.
> 1070if (!url_start || !url_end)
>   
> CID 1356973 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return PARSE_ERROR;.
> 1071  return PARSE_ERROR;



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

[GitHub] trafficserver issue #893: TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.c...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/893
  
Hmmm, still seeing branch merge conflicts :-/


---
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 #930: Add test and doc for proxy config cache select alt...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/930
  
@jacksontj Can you review the tsqa test portion 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 #930: Add test and doc for proxy config cache select alt...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/930
  
@jsime  Thoughts?


---
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 #954: [TS-4457] Via header always reports http1

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/954
  
@ericcarlschwartz 

```C++
-  if (s->state_machine->ua_session && 
(!strncmp(s->state_machine->ua_session->get_protocol_string(), "http/2", 6))) { 
//if http/2
+  if (s->state_machine->ua_session && 
(!strncmp(s->state_machine->ua_session->get_protocol_string(), "http/2", 6))) { 
// if http/2
 memcpy(via_string, "http/2 ", 7);
 via_string += 7;
-  } else { //if http/1.1 or older
+  } else { // if http/1.1 or older
```


---
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-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/954
  
@ericcarlschwartz 

```C++
-  if (s->state_machine->ua_session && 
(!strncmp(s->state_machine->ua_session->get_protocol_string(), "http/2", 6))) { 
//if http/2
+  if (s->state_machine->ua_session && 
(!strncmp(s->state_machine->ua_session->get_protocol_string(), "http/2", 6))) { 
// if http/2
 memcpy(via_string, "http/2 ", 7);
 via_string += 7;
-  } else { //if http/1.1 or older
+  } else { // if http/1.1 or older
```


Issue Time Tracking
---

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

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #954: [TS-4457] Via header always reports http1

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/954
  
Hmmm, not sure. But if you look at the link, it clearly didn't like those 
lines.


---
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-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:20
Start Date: 01/Sep/16 22:20
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/954
  
Hmmm, not sure. But if you look at the link, it clearly didn't like those 
lines.


Issue Time Tracking
---

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

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[jira] [Work logged] (TS-4806) Fix up event processor thread stacks

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:19
Start Date: 01/Sep/16 22:19
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Fix up event processor thread stacks
> 
>
> Key: TS-4806
> URL: https://issues.apache.org/jira/browse/TS-4806
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Fix event processor to create stacks on the appropriate numa node and with 
> the appropriate page size. Also, stop using the main thread as ET_NET 0 since 
> we can't control any of these aspects of it.



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

[GitHub] trafficserver issue #956: TS-4806: Fix up event processor thread stacks

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/956
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/562/ 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-4806) Fix up event processor thread stacks

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Fix up event processor thread stacks
> 
>
> Key: TS-4806
> URL: https://issues.apache.org/jira/browse/TS-4806
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Fix event processor to create stacks on the appropriate numa node and with 
> the appropriate page size. Also, stop using the main thread as ET_NET 0 since 
> we can't control any of these aspects of it.



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

[GitHub] trafficserver issue #956: TS-4806: Fix up event processor thread stacks

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/956
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/667/ 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-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:17
Start Date: 01/Sep/16 22:17
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/953
  
Fwiw, I did compare before and after, and things definitely improved. Not a 
ton, but noticeable, I think we got rid of 3 cache lines in total across both 
structs.


Issue Time Tracking
---

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

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



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

[GitHub] trafficserver issue #953: TS-4402 Fixes some config "Int" types to "Byte" ty...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/953
  
Fwiw, I did compare before and after, and things definitely improved. Not a 
ton, but noticeable, I think we got rid of 3 cache lines in total across both 
structs.


---
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 #957: TS-4801 Avoids marking parent down unless C...

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4801 Avoids marking parent down unless CONNECTION_ERROR



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

$ git pull https://github.com/zwoop/trafficserver TS-4801

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

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






---
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-4801) Are we marking parents down too aggressively?

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:16
Start Date: 01/Sep/16 22:16
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4801 Avoids marking parent down unless CONNECTION_ERROR



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

$ git pull https://github.com/zwoop/trafficserver TS-4801

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

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






Issue Time Tracking
---

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

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[jira] [Work logged] (TS-3407) Remove remnants of "h2-14" identifier

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 01/Sep/16 22:08
Start Date: 01/Sep/16 22:08
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> Remove remnants of "h2-14" identifier
> -
>
> Key: TS-3407
> URL: https://issues.apache.org/jira/browse/TS-3407
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: incompatible, newbie
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> With H2 landed on master, and the RFC finalized, we should change the 
> identifier string to just "h2".



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

[GitHub] trafficserver pull request #948: TS-3407 Removes the legacy h2-14 identifier...

[zwoop]

Github user zwoop closed the pull request at:

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


---
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-4806) Fix up event processor thread stacks

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/956
  
A cookie for @PSUdaemon  for properly setting all Github fields!!!


Issue Time Tracking
---

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

> Fix up event processor thread stacks
> 
>
> Key: TS-4806
> URL: https://issues.apache.org/jira/browse/TS-4806
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Fix event processor to create stacks on the appropriate numa node and with 
> the appropriate page size. Also, stop using the main thread as ET_NET 0 since 
> we can't control any of these aspects of it.



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

[GitHub] trafficserver issue #956: TS-4806: Fix up event processor thread stacks

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/956
  
A cookie for @PSUdaemon  for properly setting all Github fields!!!


---
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 #953: TS-4402: Fixes some config "Int" types to "Byte" t...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/953
  
@jpeach what do you mean ? The : ?


---
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-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/953
  
@jpeach what do you mean ? The : ?


Issue Time Tracking
---

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

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



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

[jira] [Assigned] (TS-4806) Fix up event processor thread stacks

[Phil Sorber (JIRA)]

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

Phil Sorber reassigned TS-4806:
---

Assignee: Phil Sorber

> Fix up event processor thread stacks
> 
>
> Key: TS-4806
> URL: https://issues.apache.org/jira/browse/TS-4806
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>
> Fix event processor to create stacks on the appropriate numa node and with 
> the appropriate page size. Also, stop using the main thread as ET_NET 0 since 
> we can't control any of these aspects of it.



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