-
Notifications
You must be signed in to change notification settings - Fork 731
Description
I have a load balancing configuration that combines zone awareness with a method that need access to the request context/headers (sticky session):
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
// get the service instances from the discovery client (Eureka in our case)
.withDiscoveryClient()
// if the request specifies an instance, filter for it
.withRequestBasedStickySession()
// of the survivors, pick one that's in our availability zone, if any
.withZonePreference()
.build(context);
}
The comments make clear the desired logic - I want same-zone routing, unless the sc-lb-instance-id cookie specifies the ID of an instance in a different zone. Consequently withZonePreference() is specified after request based sticky session. Otherwise it will only ever be possible to "stick" to an instance in the same zone.
However, in debugging this, it appears the ZonePreferenceServiceInstanceListSupplier is only implementing the get() method that does not take a request, and consequently the request is not propagated to the downstream delegate (in this case, the sticky session mechanism). It seems the ZonePreferenceServiceInstanceListSupplier should also implement Flux<List<ServiceInstance>> get(Request request) and propagate the request to the delegate.
Line 53 in 51ee785
| public Flux<List<ServiceInstance>> get() { |
While the documentation does not show any examples of combining ServiceInstanceListSuppliers like this, nothing I found in the docs suggest the list suppliers were not intended to be composable in this way.