GRPC client blocking vs async stub recommendation

Question

We are currently implementing a high throughput spring boot application using grpc-starter package https://github.com/yidongnan/grpc-spring-boot-starter, this is a client server based application. We are migrating our legacy REST end points CRUD operations to GRPC. For having best design for this service, we need help with following questions:

1. If a single immutable GRPC blocking stub client instance is accessed by multiple threads, will this be a blocking call i.e. only one RPC call is executed at any given time.

2. As per the google GRPC IO docs it is recommended not to use blocking stub to parallelize RPC call. Is this highlighting the case of multiple RPC call on same client object. https://grpc.io/docs/guides/performance/

3. Will the blocking stub use new TCP connection for every call or same TCP connection is reused.

Answer 1

If a single immutable GRPC blocking stub client instance is accessed by multiple threads, will this be a blocking call i.e. only one RPC call is executed at any given time.

No, RPCs will progress in parallel. The stub is a thin wrapper around the Channel and Channels will perform multiple RPCs simultaneously.

As per the google GRPC IO docs it is recommended not to use blocking stub to parallelize RPC call.

This is because blocking is a scaling concern. Each blocking RPC consumes a thread and threads are very large in Java (~1 MB). Async can also see reduced context switching overhead at high scale. gRPC Java is equally efficient for blocking vs async.

Note that this generally means you can use blocking without worry for any low-scale RPCs. You can choose to use async or future stubs only on the RPCs that will have many (100+) outstanding concurrently.

Will the blocking stub use new TCP connection for every call or same TCP connection is reused.

The TCP connection will be reused. gRPC Java uses the same Channel APIs for both blocking and async. So the only difference is the API you see.