[
https://issues.apache.org/jira/browse/TS-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353311#comment-15353311
]
Susan Hinrichs commented on TS-4332:
------------------------------------
Once I thought about this some more, I realized that this solution would work
for HTTP1.x over TCP, but it would not work for SSL or any higher level
protocol.
So instead I've taken the approach of just closing the connection and returning
immediately when running over the limit as @jacksontj did for
origin_max_connection in TS-4340 and TS-4341. In the case where the over limit
is detected while connecting to origin, we can return a 503 error, since we
already have a connection set up back to the client.
Do we feel that we need a delay queue to allow for some flying dutchman delayed
requests? This is the approach that was taken in TS-4340/4341.
Also added metrics to track when the limits are hit for inbound and outbound
connections.
> 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
>
>
> 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)
