On Tue, Sep 5, 2017 at 6:32 AM, Amit Saha <amitsaha...@gmail.com> wrote:
> Digging up this thread. > This thread was just shy of a year old. It would have been better to start another thread and just reference this one with a link. I guess you are suggesting, that a "client" program (which may be composed > of multiple worker threads/processes) should only have a single channel for > each gRPC backend it wants to talk to. This channel remains "open" during > the lifetime of the client. > Yeah, although saying a channel is "open" (I assume vs closed/shutdown) isn't saying much. A Channel may be "operational" without having any active connections (it'll just create one on demand). Also, I understand that in some applications it can be hard to 1) know whether you'll told to a particular backend again and 2) coordinate sharing a Channel. It's okay to use multiple Channels. But if you can use a single Channel, try to do. This backend is of course being connected to via a LB/proxy. > In the earlier conversation it would have been via client-side load balancing logic. gRPC provides an API for replacing the client-side load balancer. I was suggesting "inside" the channel via that API is the best place for this sort of logic instead of "outside" via creating multiple Channels. But it's also pretty tangential; few users should have to worry about it. -- 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%2B4M1oPDrDfS15ja7H5aCgWc1AHfdHikkqqgUG-0EkaFNUSwsw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
