[Java] Sharing ManagedChannels and Stubs - best practices?

[Ryan Michela]

What are the best practices for managing the lifecycle of ManagedChannel and client stub instances? 

DI frameworks tend to favor long-lived singleton objects. What is the best practice for building gRPC clients with DI?

1. Inject a long-lived stub wrapping a long-lived ManagedChannel
2. Locally instantiate a short-lived stub wrapping an injected long-lived ManagedChannel
3. Create a fresh stub and ManagedChannel for each "unit of work" (multiple successive calls)
4. Create a fresh stub and ManagedChannel for each request

[Rama Rao]

Some relevant conversation here https://groups.google.com/d/msgid/grpc-io/14013c59-dc14-48d7-8521-8915c32820a9%40googlegroups.com

--
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+unsubscribe@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/9f92811a-d913-4931-af95-c26a1c807513%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Spencer Fang]

In general, a ManagedChannel should be long lived because creating it is relatively expensive, but creating stubs for RPCs on the channel is cheap. I would suggest keeping a long lived shared ManagedChannel around, and creating a fresh stub for each RPC. ManagedChannel is thread safe and is designed to be shared in this way. This would be #2 in your list.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAFfmCFE9w6Wn4smqtpCOA6hqN9%3DZ_j8%3DoMTk4kS%3DR4JHC6YvVA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Spencer Fang