This sounds like a very similar we ran into recently, I haven't had a
chance to push back the patch but here it is, I'll get it into trunk
and proposed for backport to 3.2.x soon. Basically, trafficserver
cannot recover when emergency throttling has started, this patch
should fix that. There is also another issue with throttling that
we're looking into.
--- iocore/net/UnixNetAccept.cc 2012-11-19 18:21:07.376045957 -0800
+++ iocore/net/UnixNetAccept.cc 2012-11-19 18:20:38.630034423 -0800
@@ -288,8 +288,10 @@
check_throttle_warning();
if (!unix_netProcessor.throttle_error_message) {
safe_delay(NET_THROTTLE_DELAY);
- } else if (send_throttle_message(this) < 0)
+ } else if (send_throttle_message(this) < 0) {
goto Lerror;
+ }
+ now = ink_get_hrtime();
}
if ((res = server.accept(&vc->con)) < 0) {
On Tue, Nov 13, 2012 at 10:08 AM, David Carlin <[email protected]> wrote:
> I have the following config:
>
> proxy.config.net.connections_throttle = 70000 (in records.config)
> proxy.config.net.throttle_enabled = 1 (ATS default, not specified in
> records.config)
>
> The docs say ATS should start throttling when client connections reach 31500
> with the config above (90% of half of the value of
> proxy.config.net.connections_throttle).
>
> The problem I'm having is that sometimes once throttling occurs, the server
> never recovers. I cannot connect to ATS via HTTP after a throttling event,
> even long after traffic has died down. Has anyone else ever experienced
> this?
