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
