Load balancer gives back same instance under concurrent conditions

Please correct me if I'm missing something...

Based on looking at the code for both LoadBalancerClientFilter and ReactiveLoadBalancerClientFilter and the LoadBalancer implementations used for each (RibbonLoadBalancerClient and RoundRobbinLoadBalancerClient), I believe that there may be a subtle concurrency quirk that users might find surprising at first.

Based upon each of the LoadBalancerClients coming from bean definitions created within an application context specific for that service, we can pretty safely say that the LoadBalancerClient is a singleton within a service boundary. With that in place, if there is sufficient concurrency occurring through that bean in combination with the Retry filter, it's possible that a request is routed back to the same instance that it has just failed on. I would think from a user standpoint, that most developers would expect to be retried on the other instance as that's what happens under the low concurrency model [as a result of the load balancer having a round robbin strategy by default].

It'd be good to either document this as an edge case or keep the instance of the load balancer within these two filters, so that the positional instance selection can be maintained allowing for a retry on next server type of interaction.

I'll be honest, that it's a bit difficult in order to specifically recreate this issue with a demo project due to the concurrent nature, but if that's necessary then I can attempt to put something together.

Start by reading LoadBalancerClientFilter and ReactiveLoadBalancerClientFilter alongside RibbonLoadBalancerClient and RoundRobbinLoadBalancerClient. Trace how concurrent requests and the Retry filter select instances, then determine whether the result should be documented or addressed in the filters; done means the same-instance retry behavior is resolved or clearly documented.