Re: kill existing connections immediately on failed health check

Hi Joe,

On Mon, Oct 04, 2010 at 03:46:34PM -0700, Joe Williams wrote:
>
> Is it possible for haproxy to basically kill (and/or retry) established backend connections for a failed backend server as soon as it fails a content check? Basically I have some long running requests that are expected to hang, in some cases the server they are connected to goes unavailable, failing the health check, but the connection sits until the timeout is reached while no new connections are routed to it. Ideally I would be able to keep my high server timeout but have those connections closed and retried (similar to redispatch/retry) if there was a health check failure after they were established. From what I can tell redispatch and retries don't cover this case. Thoughts?

That's not possible at all and it would not be easy to do that because at the moment there's no list of per-server connections. Also, it could cause more issues than it would solve because we would often kill perfectly working connections. Very often when an application server does not respond to health checks, it basically does not accept new connections but still processes existing ones.

This is something which comes back from time to time, due to long polling requests (mainly). I'm thinking that instead of actively killing connections, maybe we should focus in shortening their timeouts. That way, working connections are not killed and idle ones quickly disappear. And this would also work for plain TCP (where this issue is often present too). And it would also avoid killing all connections too fast when a server just experiences a hickup.

Thus we could have :

	timeout server		5m
	timeout dead-server	10s

I'm not saying it would be easier (it would not in my opinion), but it would provide much cleaner results. What do you think ?

Regards,
Willy Received on 2010/10/07 23:48