Kannan J

> `TimeUnit.NANOSECONDS.convert(duration)` looks better than `Duration.toNano()` for us, as it saturates and we aren't trying to avoid TimeUnit. @ejona86 TimeUnit.NANOSECONDS.convert takes a long and a TimeUnit as arguments and returns...

About the 2nd point, yes, by overflow I meant the overflow and its handling in the exception block that we call saturation.

@ejona86 can you also look at the concern I raised above about using the TimeUnit.NANOSECONDS.convert(long, TimeUnit) approach?

[This comment](https://github.com/grpc/grpc-java/blob/fe350cfd506b426107f413818974cb1d1f23d13c/cronet/src/main/java/io/grpc/cronet/CronetClientTransport.java#L158) for example, says ``` // TODO(b/145386688): This access should be guarded by 'stream.transportState().lock'; instead // found: 'this.lock' ``` Why should it be guarded instead by stream.transportState().lock? What was...

Here is my understanding of the issue. The suggestion is that the transport should be shutdown when any of the Stream tracer methods throw an exception, to prevent the subchannel...

When you create NettyClientTransport what values are you [passing](https://github.com/grpc/grpc-java/blob/master/netty/src/main/java/io/grpc/netty/NettyClientTransport.java#L113) for keepAliveTimeInNanos, keepAliveTimeoutInNanos and keepAliveWithoutCalls, especially the last one.

Can you check if the issue occurs with the latest grpc java version (1.65.0)?

Please proceed with raising the PR.

1. FULL_SCAN mode is not necessary in the majority cases as [cited](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers#weighted-least-request) in the envoyproxy site that gRPC also implemented. 2. Regarding avoiding picking the same endpoint twice, this is...

From your observation what is the reason the two healthy servers were not receiving any traffic since the picking the target endpoint is done on a per RPC basis?