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/c8560fe6-2305-4675-a98b-beb8ec794c68%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
