On 28 мая 2014 г., at 11:13, Willy Tarreau <w...@1wt.eu> wrote: > Hi Dmitry, > > So worked a bit on this subject. It's far from being obvious. The problem > is that at the moment where we decide of the 1s delay before a retry, we > don't know if we'll end up on the same server or not. > > Thus I'm thinking about this : > > - if the connection is persistent (cookie, etc...), apply the current > retry mechanism, as we absolutely don't want to break application > sessions ;
I agree. > > - otherwise, we redispatch starting on the first retry as you suggest. But > then we have two possibilities for the delay before reconnecting. If the > server farm has more than 1 server and the balance algorithm is not a hash > nor "first", then we don't apply the delay because we expect to land on a > different server with a high probability. Otherwise we keep the delay > because we're almost certain to land on the same server. > > This way it continues to silently mask occasional server restarts and is > optimally efficient in stateless farms when there's a possibility to quickly > pick another server. Do you see any other point that needs specific care ? I would export that magic "1 second" as a configuration parameter (with 0 meaning no delay). After all, we could fail to connect not only because of server restart, but also because a switch or a router dropped a packet. Other than that, sounds good. Thanks!
