The retry/hedging attempts will always pick an currently available endpoint provided by the load balancer. If you are using pick_first load balancing (which is default), it will always provide the first endpoint if it's available. If you are using round_robin load balancing, then each retry/hedging attempts will pick next available endpoint from load balancer, but if 2 out of 3 endpoints are unreachable, it will always use the only available one. This is by design.
On Thursday, November 14, 2019 at 3:20:24 PM UTC-8, David M wrote: > > I am using Java gRPC version 1.24.1. When debugging some timed out > requests I found out that sometimes client calls all hedging requests ( 3 > in my case) on the same server endpoint. > NameResolver.Listener.onAddresses() got updated with 3 distinct endpoints > before first call was made. > Is it a bug in gRPC code ? Even if 2 out of 3 servers were unreachable, > having all hedging attempts go to a single endpoint is not the best option. > > > status-code=DEADLINE_EXCEEDED status-description=deadline exceeded after > 9999958644ns. [closed=[], open=[[remote_addr=xxx.com/xxx.xxx.xxx.xxx:3112], > [remote_addr=xxx.com/xxx.xxx.xxx.xxx:3112], [remote_addr=xxx.com/xxx.xxx > .xxx.xxx:3112]]] > > Thanks, > David > > > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/66a75f46-1358-487e-a783-ee210aedc253%40googlegroups.com.
