[jira] [Work logged] (TS-4601) Connection error from origin_max_connection with origin_max_connections_queue set to 0 should not retry
[ https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26699=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26699 ] ASF GitHub Bot logged work on TS-4601: -- Author: ASF GitHub Bot Created on: 20/Aug/16 00:17 Start Date: 20/Aug/16 00:17 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/762 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/565/ for details. Issue Time Tracking --- Worklog Id: (was: 26699) Time Spent: 1h (was: 50m) > Connection error from origin_max_connection with origin_max_connections_queue > set to 0 should not retry > --- > > Key: TS-4601 > URL: https://issues.apache.org/jira/browse/TS-4601 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 1h > Remaining Estimate: 0h > > While adding a metric to track the number of times a connection to origin is > dropped due to being over the origin_max_connections limit, I noticed that > the count was increments three times as fast as I expected from my > experiment. My connection retry count was 3. I changed the logic to set the > current attempts to max to avoid the retries in that case. > [~jacksontj] avoiding the retries makes sense in this case, right? > I also propose adding a proxy.process.http.origin_connections_throttled > metric to track how many connections to origin are being error'ed out the > origin_max_connection limit. The metric is only incremented when the queue > is 0 or we are over the delay queued limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4601) Connection error from origin_max_connection with origin_max_connections_queue set to 0 should not retry
[ https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26698=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26698 ] ASF GitHub Bot logged work on TS-4601: -- Author: ASF GitHub Bot Created on: 20/Aug/16 00:15 Start Date: 20/Aug/16 00:15 Worklog Time Spent: 10m Work Description: Github user shinrich closed the pull request at: https://github.com/apache/trafficserver/pull/762 Issue Time Tracking --- Worklog Id: (was: 26698) Time Spent: 50m (was: 40m) > Connection error from origin_max_connection with origin_max_connections_queue > set to 0 should not retry > --- > > Key: TS-4601 > URL: https://issues.apache.org/jira/browse/TS-4601 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > While adding a metric to track the number of times a connection to origin is > dropped due to being over the origin_max_connections limit, I noticed that > the count was increments three times as fast as I expected from my > experiment. My connection retry count was 3. I changed the logic to set the > current attempts to max to avoid the retries in that case. > [~jacksontj] avoiding the retries makes sense in this case, right? > I also propose adding a proxy.process.http.origin_connections_throttled > metric to track how many connections to origin are being error'ed out the > origin_max_connection limit. The metric is only incremented when the queue > is 0 or we are over the delay queued limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4601) Connection error from origin_max_connection with origin_max_connections_queue set to 0 should not retry
[ https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26697=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26697 ] ASF GitHub Bot logged work on TS-4601: -- Author: ASF GitHub Bot Created on: 20/Aug/16 00:14 Start Date: 20/Aug/16 00:14 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/762 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/460/ for details. Issue Time Tracking --- Worklog Id: (was: 26697) Time Spent: 40m (was: 0.5h) > Connection error from origin_max_connection with origin_max_connections_queue > set to 0 should not retry > --- > > Key: TS-4601 > URL: https://issues.apache.org/jira/browse/TS-4601 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > While adding a metric to track the number of times a connection to origin is > dropped due to being over the origin_max_connections limit, I noticed that > the count was increments three times as fast as I expected from my > experiment. My connection retry count was 3. I changed the logic to set the > current attempts to max to avoid the retries in that case. > [~jacksontj] avoiding the retries makes sense in this case, right? > I also propose adding a proxy.process.http.origin_connections_throttled > metric to track how many connections to origin are being error'ed out the > origin_max_connection limit. The metric is only incremented when the queue > is 0 or we are over the delay queued limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4601) Connection error from origin_max_connection with origin_max_connections_queue set to 0 should not retry
[ https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26693=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26693 ] ASF GitHub Bot logged work on TS-4601: -- Author: ASF GitHub Bot Created on: 20/Aug/16 00:02 Start Date: 20/Aug/16 00:02 Worklog Time Spent: 10m Work Description: Github user shinrich commented on the issue: https://github.com/apache/trafficserver/pull/762 Addressed @bryancall 's comment via squashed commit. Issue Time Tracking --- Worklog Id: (was: 26693) Time Spent: 0.5h (was: 20m) > Connection error from origin_max_connection with origin_max_connections_queue > set to 0 should not retry > --- > > Key: TS-4601 > URL: https://issues.apache.org/jira/browse/TS-4601 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > While adding a metric to track the number of times a connection to origin is > dropped due to being over the origin_max_connections limit, I noticed that > the count was increments three times as fast as I expected from my > experiment. My connection retry count was 3. I changed the logic to set the > current attempts to max to avoid the retries in that case. > [~jacksontj] avoiding the retries makes sense in this case, right? > I also propose adding a proxy.process.http.origin_connections_throttled > metric to track how many connections to origin are being error'ed out the > origin_max_connection limit. The metric is only incremented when the queue > is 0 or we are over the delay queued limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4601) Connection error from origin_max_connection with origin_max_connections_queue set to 0 should not retry
[ https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26684=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26684 ] ASF GitHub Bot logged work on TS-4601: -- Author: ASF GitHub Bot Created on: 19/Aug/16 23:28 Start Date: 19/Aug/16 23:28 Worklog Time Spent: 10m Work Description: Github user shinrich commented on a diff in the pull request: https://github.com/apache/trafficserver/pull/762#discussion_r75564926 --- Diff: proxy/http/HttpConfig.cc --- @@ -809,6 +809,8 @@ register_stat_callbacks() (int)https_incoming_requests_stat, RecRawStatSyncCount); RecRegisterRawStat(http_rsb, RECT_PROCESS, "proxy.process.https.total_client_connections", RECD_COUNTER, RECP_PERSISTENT, (int)https_total_client_connections_stat, RecRawStatSyncCount); + RecRegisterRawStat(http_rsb, RECT_PROCESS, "proxy.process.http.origin_connections_throttled", RECD_COUNTER, RECP_PERSISTENT, --- End diff -- Actually the throttling limit affects both incoming and outgoing connections. I could create origin_connections_throttled_in and origin_connections_throttled out. Issue Time Tracking --- Worklog Id: (was: 26684) Time Spent: 20m (was: 10m) > Connection error from origin_max_connection with origin_max_connections_queue > set to 0 should not retry > --- > > Key: TS-4601 > URL: https://issues.apache.org/jira/browse/TS-4601 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > While adding a metric to track the number of times a connection to origin is > dropped due to being over the origin_max_connections limit, I noticed that > the count was increments three times as fast as I expected from my > experiment. My connection retry count was 3. I changed the logic to set the > current attempts to max to avoid the retries in that case. > [~jacksontj] avoiding the retries makes sense in this case, right? > I also propose adding a proxy.process.http.origin_connections_throttled > metric to track how many connections to origin are being error'ed out the > origin_max_connection limit. The metric is only incremented when the queue > is 0 or we are over the delay queued limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4601) Connection error from origin_max_connection with origin_max_connections_queue set to 0 should not retry
[ https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=25676=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25676 ] ASF GitHub Bot logged work on TS-4601: -- Author: ASF GitHub Bot Created on: 19/Jul/16 08:20 Start Date: 19/Jul/16 08:20 Worklog Time Spent: 10m Work Description: Github user bryancall commented on a diff in the pull request: https://github.com/apache/trafficserver/pull/762#discussion_r71290755 --- Diff: proxy/http/HttpConfig.cc --- @@ -809,6 +809,8 @@ register_stat_callbacks() (int)https_incoming_requests_stat, RecRawStatSyncCount); RecRegisterRawStat(http_rsb, RECT_PROCESS, "proxy.process.https.total_client_connections", RECD_COUNTER, RECP_PERSISTENT, (int)https_total_client_connections_stat, RecRawStatSyncCount); + RecRegisterRawStat(http_rsb, RECT_PROCESS, "proxy.process.http.origin_connections_throttled", RECD_COUNTER, RECP_PERSISTENT, --- End diff -- It would be better to use connections_throttled_out. We talked about using this at the standard in identifying connections (_out|_in). Issue Time Tracking --- Worklog Id: (was: 25676) Time Spent: 10m Remaining Estimate: 0h > Connection error from origin_max_connection with origin_max_connections_queue > set to 0 should not retry > --- > > Key: TS-4601 > URL: https://issues.apache.org/jira/browse/TS-4601 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > While adding a metric to track the number of times a connection to origin is > dropped due to being over the origin_max_connections limit, I noticed that > the count was increments three times as fast as I expected from my > experiment. My connection retry count was 3. I changed the logic to set the > current attempts to max to avoid the retries in that case. > [~jacksontj] avoiding the retries makes sense in this case, right? > I also propose adding a proxy.process.http.origin_connections_throttled > metric to track how many connections to origin are being error'ed out the > origin_max_connection limit. The metric is only incremented when the queue > is 0 or we are over the delay queued limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
