+1
----- Original Message -----
> 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?
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: [email protected]
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
