async gRPC - error conditions

[Stephan Menzel]

Hello group,

I am in the process of transforming a number of gRPC services to an async approach. To this end, I have implemented a base architecture for my calls, starting out with the async server example in the code and extending it with a template base class for my calls. Unlike the example, the actual work is done in a workerthread running a number of fibers where I post all the work into.

As I get along transforming all the calls a question arises that puzzled me for quite some time and that I like to find an answer for in order to get my implementation stabilized. I am referring to this example: https://github.com/grpc/grpc/blob/master/examples/cpp/helloworld/greeter_async_server.cc

The question is: What happens when things go south?

For example, when the caller drops the connection because it runs into its timeout. What happens to the call? Will it somehow be shut down? And how do I notice that? Since my actual work is happening in another thread I need to understand the lifecycle of the object better.

The same goes for the call itself to timeout. Some of my implementations involve blocking file IO and other stuff that may exceed a timeout I am setting myself. Am I right assuming that I'm supposed to call Finish() anyway? And would I be able to tell Finish() that this call is faulty or would I use the actual response payload to relay this information?

What other error conditions should I take care of that the example doesn't cover? I'm thinking unparseable calls? Unimplemented methods? Anything really.

Can anyone shed some light on this?

Best regards...

Stephan

[Carl Mastrangelo]

Partial answers:

Callers don't drop connections due to timeouts.   Rpcs can drop due to timeouts, but not really connections.  In the event that the RPC times out, the client-side loadbalancer will decide if the RPC can be rescheduled onto a new connection.   gRPC comes with two load balancers by default: PickFirst and RoundRobin.  PickFirst prefers to use a single connection, even if there are multiple backends.  Pick first is also the default.  Round Robin spreads load evenly across backends, and can send new RPCs to non failing connections.  

I can't comment on the C++ API, unfortunately.