Clarification on gRPC AsyncNext usage

[luca.ma...@sysdig.com]

Hi everyone,

I'm trying to integrate gRPC in my application and I'm having some issues. This is mostly the workflow I have in my app:

1. a thread that does a bunch of different things

2. every second reads gRPC response of the request sent last second

3. at the same time it sends a new gRPC request to another process

It's very important for us that every second we read the response calculated by the other process. What I did so far is:

1. use AsyncNext with timeout 0 on CompletionQueue to read any data available

2. Compose a new request and send it via Stub::AsyncSayHello and Finish()

(just using this an example https://github.com/grpc/grpc/blob/master/examples/protos/helloworld.proto#L27, my code is equivalent)

But it does not quite work, basically the server responds immediately but the first call to AsyncNext just gives a timeout, calling again AsyncNext instead gives the response.

My questions is: Isn't there any API that allows to *read anything you can from the socket*?

I can also just call AsyncNext multiple times until it's done but how can I know that there is yet something else to parse if I just receive TIMEOUT?

My understanding is that I just need to call AsyncNext to keep things going, how do you suggest to implement this? Like having a different thread just doing AsyncNext for all my gRPC calls?

Anybody that can explain this behaviour better to me would be very appreciated, I'll be happy to send PR to update documentation if afterwards if needed.

Thanks,

Luca

[ncte...@google.com]

Sorry for the delayed response. You should take a look at greeter_async_client2.cc, it is a good example of client code that has a dedicated thread to drive work forward on RPCs. In the main body of the file, we start a thread that loops over AsyncCompleteRpc, which will block on AsyncNext, and proceed whenever there are bytes to be read from the wire.

For a more complex example of this type of pattern, take a look at our QPS Driver codebase (especially client.h and client_async.cc). That has a similar pattern, but allows threading to be controlled more finely (and supports all types of streaming).

[Luca Marturana]

Hi

Thanks for the suggestion! I’ll try your approach and see if it works better for my usecase.

Regards,

Luca

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/8vxfDjvxtSY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@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/0d839a80-1968-446a-ba54-0f2933228dac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Luca Marturana

Engineering Manager / Sysdig