[ https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26693&page=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)