Thanks for your reply, Eric! The bug I observed only happened in production environment, and I haven't figured out a way to repro it locally. I will definitely let you know if there is any updates.
On Fri, Sep 16, 2016 at 9:25 PM Eric Anderson <ej...@google.com> wrote: > Reading another thread made me want to tweak my statement: > >> Only in very heavy throughput (when we start talking about trying to >> fully saturate a server NIC) should you even begin to consider do something >> else. > > > Even in that case you probably shouldn't use multiple Channels. Instead, > you would want a load balancer that might make multiple connections to the > backend. Use different channels when you are contacting different backends. > That is the only form of "channel pool" you might want: to look up a single > shared Channel per backend. > > On Fri, Sep 16, 2016 at 8:49 PM, Eric Anderson <ej...@google.com> wrote: > >> You should share a single channel across threads. Only in very heavy >> throughput (when we start talking about trying to fully saturate a server >> NIC) should you even begin to consider do something else. >> >> I can't say what bug you experienced before, but only doing one RPC on >> each channel at a time is simpler and is less likely to encounter bugs and >> interop issues. But if/when you encounter something like that, please bring >> it to our attention so that it can be addressed. >> >> On Thu, Sep 15, 2016 at 5:01 PM, ran.bi via grpc.io < >> grpc-io@googlegroups.com> wrote: >> >>> Hi >>> >>> I want to know what is the best practice to use GRPC client channels. >>> For each GRPC client-server pair, should I just create a single channel >>> that is shared among all threads, or should I create a pool of channels and >>> make sure one channel is used by one thread at a time? >>> >>> I am asking this is because I used to run into mysterious issues that >>> some channel got stuck in the middle of some long stream RPC and the client >>> thread blocks forever, while the same issue never happens to "channel pool" >>> model. >>> >>> Best >>> >>> -- >>> 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+unsubscr...@googlegroups.com. >>> To post to this group, send email to grpc-io@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/14013c59-dc14-48d7-8521-8915c32820a9%40googlegroups.com >>> <https://groups.google.com/d/msgid/grpc-io/14013c59-dc14-48d7-8521-8915c32820a9%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/CA%2BMQGYoh%3D4qRK-Jhjo4eb1y3nXawuhXZQXS5rMhk%3DzoZeik5pw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
