tree a5989f8ad27f70d9ee8f73841c56877c15186f8d
parent d67b10fae2e4c48b15867f5e6a47a2746961cad7
author Willy Tarreau <w@1wt.eu> 1664801794 +0200
committer Christopher Faulet <cfaulet@haproxy.com> 1666701616 +0200

BUG/MINOR: backend: only enforce turn-around state when not redispatching

In github issue #1878, Bart Butler reported observing turn-around states
(1 second pause) after connection retries going to different servers,
while this ought not happen.

In fact it does happen because back_handle_st_cer() enforces the TAR
state for any algo that's not round-robin. This means that even leastconn
has it, as well as hashes after the number of servers changed.

Prior to doing that, the call to stream_choose_redispatch() has already
had a chance to perform the correct choice and to check the algo and
the number of retries left. So instead we should just let that function
deal with the algo when needed (and focus on deterministic ones), and
let the former just obey. Bart confirmed that the fixed version works
as expected (no more delays during retries).

This may be backported to older releases, though it doesn't seem very
important. At least Bart would like to have it in 2.4 so let's go there
for now after it has cooked a few weeks in 2.6.

(cherry picked from commit 406efb96d135efe1d5a85bf58c589f7b6dbd8c70)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 22beb2ad21e23c5caccc5007c4d65dc388aa6edd)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 2e316e968e6c35c81e835ea670961ca25d49eed2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>