btw if current iphash1 is stable in both cases (failover & recovery of backend from static list) when discovery kind="static" - it should suffice. However it is not clearly mentioned in GB documentation/code.

@illarion could you please add more description to Iphash1/iphash ?

@nickdoikov - is it known what is the behavior for iphash1 in case of static backends list where no new servers are discovered but some can fail and recover?

@AmitBawer yes it is known and it's really simple: in case of failure of some backend, its clients get rebalanced to other backends. Other clients are not rebalanced. If the affected backend recovers, only its clients get rebalanced back.

@illarion / @nickdoikov its important for our use-case that stickiness is preserved, which means that if some clients are redirected from a failed backend X to another backend Y, then even if X recovers, the clients redirected to Y remain there.

Thanks for your contribution, @AmitBawer
Sticky iphash implementation seems something very nice to have in gobetween.
We'll work on "sticky" version as new iphash2 balance method.
I think it will accept some parameters like expiration time and max sticky table size, like in haproxy.

@yyyar Thank you indeed, looking forward for such functionality.

Reading the requirement of @AmitBawer an option named no_rebalance_after_recover came to mind ... Although I am not sure of the exact need. 😁😁😁

Maybe just a delay for rebalance could suffice, I dunno!

@shantanugadgil , i believe that if no rebalance never occurs after recovery we might end up theoretically in situation where all clients are forever redirected to the ever-healthy backend and the recovered one would remain idle. Unless you have meant something else.

Thanks for your contribution, @AmitBawer
Sticky iphash implementation seems something very nice to have in gobetween.
We'll work on "sticky" version as new iphash2 balance method.
I think it will accept some parameters like expiration time and max sticky table size, like in haproxy.

I wonder if sticky is actually just a reasonable option for any of the balance methods.
ie, you might like the 'weight' balance method to be sticky or not sticky, same for iphash, priority, etc etc.
I recently submitted a pull request for a 'priority' balance mechanism, and am extending that mechanism to include another called 'stickyPriority'.
Thinking about it more, if you wrapped "stickyXXX" to just do the "sticky" component, then call the normal balance function "XXX" for new sessions, you'd probably have a nice extensible framework moving forward...

so, I wrote 'sticky priority' and submitted it, see #209
its seems to work for me & my use case.

@illarion / @nickdoikov its important for our use-case that stickiness is preserved, which means that if some clients are redirected from a failed backend X to another backend Y, then even if X recovers, the clients redirected to Y remain there.

It meets this criteria mentioned by @AmitBawer above.