On Oct 7, 2010, at 2:48 PM, Willy Tarreau wrote:

> 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 ?



Willy,

I think that should work, my issue is definitely long polling requests as you 
suggested. The only thing in addition to this would be to retry the request but 
failing faster might be good enough for now. As I mentioned in my second email 
doing ACL based timeouts would also work for me since I know which urls I 
expect to take a long time to return.

Thanks!

-Joe


Name: Joseph A. Williams
Email: [email protected]
Blog: http://www.joeandmotorboat.com/
Twitter: http://twitter.com/williamsjoe


Reply via email to