[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?
This approach doesn't decrease the client->server throughput ? On Wednesday, 21 November 2018 17:24:21 UTC+1, m...@stackrox.com wrote: > > I did, sort of. I made the streaming bidirectional (basically rpc > MyMethod (stream ClientMsg) return (stream google.protobuf.Empty) ), and > attempting client-side recv's now gives an option to reliably check for > error. I also wrapped the whole grpc interface into a select-style > interface (as I didn't want to use threads and thought the async interface > is overly complicated, especially considering I didn't *really* need that > full-duplex functionality). I can share it here if you're interested (need > to check w/ employer but shouldn't be an issue). > > Hope that helps, > Malte > > On Wednesday, November 21, 2018 at 8:17:04 AM UTC-8, ple...@swissonline.ch > wrote: >> >> Hi, >> >> I face the same problem, did you find a solution ? >> > -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/4483c45f-68b4-4eae-aeed-6bcd2ab7f3f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?
Also I have to say I'm puzzled as well about the client streaming use case: https://groups.google.com/forum/#!topic/grpc-io/7alTzx7YRKE On Friday, 21 September 2018 09:17:34 UTC+2, Malte Isberner 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, m...@stackrox.com > 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/1b76969b-3240-4d5b-9552-0a6b24644033%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[grpc-io] Re: C++ API, unidirectional streaming: How to tell if receiver closed the connection?
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, malte.i...@gmail.com > 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, m...@stackrox.com >> 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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.
[grpc-io] Retrieve Server Reply before client streams terminates.
I can read from documentation: "A client-streaming RPC is also similar to our simple example, except the client sends a stream of requests to the server instead of a single request. The server sends back a single response, typically but not necessarily after it has received all the client’s requests, along with its status details and optional trailing metadata." Usually the client does: - create channel - creaet stub - perform the writer = stub->foo(context, reply); - loop on: writer->Write(request) - writer->Done() - writer->Finish() - At this point I can read the reply now my question is how can I read the reply before the loop is over? Some time the server indeed stops performing the read loop notifying that there is no need for more requests. -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/1b8afe4c-088d-47dd-90e8-7f5cd0949c6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
