Kannan J
Kannan J
I noticed your version of gRPC-Java is old. Can you try with the latest released version and see if it still is an issue there?
The CronetMetrics handling all happens in the Cronet code itself, not in the grpc-cronet code. Can you check with gRPC Java 1.63.2 that used an earlier version of cronet API...
Yes, as seen from `at io.grpc.netty.shaded.io.grpc.netty.NettyClientHandler$2.onGoAwayReceived(NettyClientHandler.java:284)` the server has sent a go away frame because it got terminated. You should check the gRPC server side to check the reason for...
@Tanusyadav did you try with a newer version of gRPC-Java?
A UDS name resolver wouldn't check the proxySelector, so disabling the proxy selector (setting a noop) sounds fine. It is annoying we don't know what error actually happened, though. >>>...
(2) is easy and can be done. (1) would involve introducing a new sub-channel connectivity state since it is a non-transient failure, and have a way of marking pending transports...
Please add unit tests.
You are presenting the state of how memory is handled in grpc, but not necessarily indicative of a problem. There can be optimizations but each with their own trade-offs. 1....
We are aware of the higher than we would like memory usage but we don't see a way to improve it right now in the gRPC server code. And there's...
The gRPC client cannot make such a decision as to at what size to enable gzip compression that because the size restriction is on the receiver specified via [ManagedChannelBuilder::maxInboundMessageSize](https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannelBuilder.html).