Thanks for the answer! I do not think this is a good design. The main goal for hedging is to execute remote call on a different servers. Running heading calls on the same server is worse that not having hedging at all. Is there a plan to redesign it ?
On Wednesday, November 20, 2019 at 4:36:33 PM UTC-8, Penn (Dapeng) Zhang wrote: > > 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 grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/bb2f9f37-ec53-4a5e-9c15-e66eeb54d051%40googlegroups.com.
