Hi Alex,
>From the log, I found the error is located at client-side. The gRPC client
sends reset stream frame with error code 2 indicating internal error, and
its channel state somehow becomes SHUTDOWN.
Also, I tried your code in Linux, it works fine without any error. I had
another failed attempt
The ClientContext object needs to be alive for the entire duration of the
RPC. The scope of your ClientContext is too limited. I suggest
restructuring your code such that RPC invoking function is separated from
the channel state checking. Also, gRPC will automatically try to connect
the channel
Hi,
There would be a unique stream per call. The threading model you use will
depend a lot on the application and the performance requirements.
I think there is a slight confusion here about the sync and async API. In
the async API, reads and writes do not block, i.e., the calls should return
grpc github issue: https://github.com/grpc/grpc/issues/18554
StackOverflow post:
https://stackoverflow.com/questions/55460086/client-channel-unusable-after-a-network-reset
Summary: If a client channel is in a READY state and the network is
disconnected, the channel becomes unusable and the clien
Hi Lidi,
I've set those environment variables you mentioned and I've attached the
log files (serverlog.txt and clientlog.txt).
Since I reported this issue, I've upgrade the Python version of gRPC, so
the attached log files were created with grpcio 1.19.0
Do they give you any hint as to what could
