[jira] [Work logged] (TS-4332) proxy.config.net.connections_throttle should allow for immediate error return when accepts reach throttle limit

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

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

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

    https://github.com/apache/trafficserver/pull/761
  
    @bcall so the idea is that we will remove the existing proxy.config.net.connections_throttle setting in the 7.0 time frame?  This PR is changing the existing throttle setting to allow for connections to be closed immediately when over limit.  As it is implemented currently, the connection attempts are just retried later making this setting pretty useless when under load.  
    
    Independent of the proxy.config.net.connections_throttle setting, having a no-throttle port setting would still be useful in the LRU scenario. There may be intra-pod communication channels you don't want to shutdown.  What are your thoughts there?


Issue Time Tracking
-------------------

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

> proxy.config.net.connections_throttle should allow for immediate error return when accepts reach throttle limit
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: TS-4332
>                 URL: https://issues.apache.org/jira/browse/TS-4332
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Network
>            Reporter: Susan Hinrichs
>            Assignee: Susan Hinrichs
>             Fix For: sometime
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> When the throttling kicks in future connections to origins will cause a 502 to be returned to the user agent.
> But when an accept happens during the throttling period, a message is only sent if the unix_netProcessor.throttle_error_message member variable is set.  In the current code, this member variable is never set.  If the variable is not set, the logic blocks for 100ms and tries again.
> This spinning causes the ATS process to waste resources.  It would be better to immediately turn around and send an error response (probably 503 instead of 502).
> I tested a build that hard coded an error message and it seemed to recover much better.
> I propose adding some config variables to control the throttling behavior.
> proxy.config.connections_throttle.error_code  - HTTP response code to return (or just hard code this to 503)
> proxy.config.connections_throttle.error_page - Reference to an error page to return.
> If both are unset, the existing delaying logic is used.  If either is set, either a error header or a header and body are returned immediately.



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