On Wed, 26 Dec 2018 at 23:04, Lukas Tribus <lu...@ltri.eu> wrote:
> redispatch never worked for hash based alghoritms, as the code
> (BE_LB_LKUP_CHTREE -> chash_get_next_server()) would only have been
> called for BE_LB_KIND_RR, which doesn't make sense. Fix this by also
> going down this code path when the BE_LB_KIND is BE_LB_KIND_HI.
> Reported by Oskar Stenman on discourse:
> https://discourse.haproxy.org/t/balance-uri-consistent-hashing-redispatch-3-not-redispatching/3344
> Can be backported to 1.6.

Actually my intention was to set this as RFC, with the following
comments, but git send-mail was faster:

I'm not 100% sure whether "option redispatch" was only intended to
break cookie persistence, but not other lb algorithms. Docs are
ambiguous about this.

However, since option redispatch is configurable per backend, it
doesn't make a lot of sense to exclude hash based algorithms from
redispatch functionality.

Also, the fact the code is already there, it's just never called
(s->be->lbprm.algo is never BOTH BE_LB_KIND_RR and BE_LB_LKUP_CHTREE)
makes me think that this was just an oversight.

Backporting this could change behavior as redispatch suddenly begins
to work in such a situation; however this is expected and a correct
configuration fixes it immediately.


Reply via email to