I have the same issue look at this: https://github.com/grpc/grpc/issues/17236
I have kinda solved (I need to do some further tests) observing the underlying channel status. On Friday, 21 September 2018 09:24:44 UTC+2, Malte Isberner wrote: > > One detail I forgot in my example, which is now happily running for >10m > without reporting an error on Write(): The messages I send are indeed very > small, but I'm passing `grpc::WriteOptions().set_write_through()` to every > Write call, so buffering should not be the issue here (and if I understand > things correctly, it shouldn't be even without that option). > > > On Friday, September 21, 2018 at 12:17:34 AM UTC-7, [email protected] > wrote: >> >> Ok, it seems like the situation is even worse, and this is really >> frustrating. >> >> Using a Go GRPC server (didn't test anything else), I cannot even get >> `Write()` to fail even when the remote server does not implement the method >> I'm calling! I'm sending a message every 5 seconds to a GRPC server that >> doesn't implement the method/service, and I keep getting `true` return >> values (code is running for >5m now). Now, I can call `Finish` at any time >> and will then in fact get the "unknown service xyz" in the status response, >> but for that I'd have to close the stream - doesn't work with my use case. >> >> I somehow can't believe that this is really the state of affairs with the >> GRPC C++ API, but I've looked through most of the API and don't see a >> solution. I apologize if that sounds harsh, but if it is impossible to make >> a client-side streaming RPC call without knowing whether all the data gets >> effectively sent to /dev/null before closing this stream (regardless of >> session length), it seems that client-side streaming is effectively >> unusable from C++..? (This very use case works absolutely fine in Golang) >> >> On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, [email protected] >> wrote: >>> >>> Hi, >>> >>> I'm having trouble using the GRPC C++ API for a unidirectional stream >>> RPC (client streaming, client is written in C++, server in Go). >>> >>> Unless I'm missing something, it seems that the only way to find out if >>> the remote (receiving) end of the stream aborted the GRPC call is by >>> actually calling Write(). For streaming connections that send data only >>> infrequently (but which need to be streaming nonetheless, due to >>> statefulness of a single "call" and ordering guarantees), this seems very >>> unsatisfying. Even when using the stream to send keep-alives at regular >>> intervals (which I do not believe should be done at the application level), >>> the fact that a call to `Write >>> >> -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/30122907-c20e-4454-9546-6cb03ea1f884%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
