Do I need to pool ManagedChannel instances for a multithreaded Java GRPC (1.1.2) client?

Question

TL;DR

Does grpc-java's ManagedChannel have an implicit connection pool or is the pooling of ManagedChannel instances the responsibility of the user?

---

So, I am using java grpc 1.1.2 with protoc 3.2.0. It seems to me that there's no implicit support (as of now) for connection pooling that grpc provides for clients. It seems, however, that the abstraction of a connection in grpc, i.e. the ManagedChannel object does indeed work with multiple TCP connections. Is that correct? If so, does the ManagedChannel come with connection pooling along with it? If that is the case, I probably don't have to worry about the connection pooling, given that the channel is thread-safe and I can simply use a single ManagedChannel instance across my client. However, I might indeed have to pool these channel objects too for greater throughput if need be. Is there such an implementation (pooling of channels) that does this for me in grpc itself?

Answer 1

Yes, ManagedChannel does the connection pooling, and you only need one. It will automatically create and destroy connections as they are needed.

Answer 2

Since you said you wanted pooling for greater throughput, I assume you want to create and pool multiple connections for one address in a channel. It was not supported, as the channel impl used to create only one connection per address. With the LBv2 which will soon supercede the old version, it's now possible with a custom LoadBalancer in which you can create as many Subchannels for a connection as you wish.

You can refer to the stock pick-first and round-robin LoadBalancers on how to write your own LoadBalancer.