Responses inline On Tuesday, May 21, 2019 at 7:07:11 AM UTC-7, sut...@gmail.com wrote: > > Hi folks, > > I'm interested in understanding how gRPC-Java might behave in a > pathological situation where a vast number of client requests start timing > out causing a deadline exceeded avalanche. If a gRPC java client with 50k > "sessions" is partitioned away from the server, it might start seeing a > very large number deadline exceeded. Subsequent retry attempts might also > meet the same fate---adding another 50k deadline exceeded. > > What might be an effect on gRPC java due to such an avalanche of deadline > exceeded? Are the deadlines reported to the caller in a timely fashion? > What might be the impact on well-behaved sessions? >
They are reported. Both the client and server know the deadline, so there is no risk of one side not being aware. If you are using Netty, the deadlines are enforced using the EventLoopGroup's scheduler. I'm not sure if they use Netty's HashedWheelTimer. > > Client might do clever things like waiting a random backoff before > retrying to avoid clustering. > gRPC has an in progress retry mechanism that does auto backoff. By default, there are no RPC retries, so you would need to do this at the application level today. > > Does gRPC Java use a scalable approach to track deadlines? A paranoid > client might rely on its own HashedTimerWheel > <https://netty.io/4.0/api/io/netty/util/HashedWheelTimer.html>-based > deadline exceeded reporting mechanism without relying on gRPC. Do you see a > need for such a thing? > > Regards, > Sumant > -- 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/c03ec03a-9cce-42a2-8d09-3f2ffb7ae4d7%40googlegroups.com.
