Hi Dmitry, On Wed, May 28, 2014 at 11:13:24AM +0200, Willy Tarreau wrote: > On Wed, May 28, 2014 at 01:11:47PM +0400, Dmitry Sivachenko wrote: > > On 28 ?????? 2014 ??., at 13:06, Willy Tarreau <w...@1wt.eu> wrote: > > > > > > > > OK but then you make an interesting point with your very low timeout > > > connect. > > > What about using the min of timeout connect and 1s then ? Thus you can > > > simply > > > use your lower timeout connect as this new timeout. Would that be OK for > > > you ? > > > > > > > > > Sounds reasonable (provided we are talking only about redispatch to the same > > server, not to the other one). > > of course :-) > I'll try to sketch something like this then.
Done! I've just pushed this. In the end I preferred not to apply this principle to leastconn since there are some situations where leastconn farms can be highly unbalanced (after a server restart) so killing the delay could result in hammering the new fresh server harder. So this is what happens now : - if we're on a round-robin farm with more than 1 active server and the connection is not persistent, then we redispatch upon the first retry since we don't care at all about the server that we randomly picked. - when redispatching, we kill the delay if the farm is in RR with more than one active server. - the delay is always bound by the connect timeout so that sub-second timeouts will lead to shorter retries even for other cases. I just realized during my tests that this way you can have a retries value set to the number of servers and scan your whole farm looking for a server. Yeah this is ugly :-) Regards, Willy
