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/ms >> gid/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%2B4M1oNFzxWYAj%3DTv%3DJLZmuEqLQH40FTyK0fXAtop5H1Lf%3D1nQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
