[grpc-io] Best practice for client channel

[ran.bi via grpc.io]

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.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Best practice for client channel

['Eric Anderson' via grpc.io]

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
> 
> .
> 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%2B4M1oM-pEByLqqV2J87w%3D%3DuQ%3Da1o16rVdxyjeqGdQePf6h9pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Best practice for client channel

['Eric Anderson' via grpc.io]

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  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
>> 
>> .
>> 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.

Re: [grpc-io] Best practice for client channel

['Ran Bi' via grpc.io]

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  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  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
>>> 
>>> .
>>> 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.

Re: [grpc-io] Best practice for client channel

[Amit Saha]

On Saturday, September 17, 2016 at 2:25:54 PM UTC+10, Eric Anderson 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.
>

Digging up this thread. 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. This backend is 
of course being connected to via a LB/proxy.

Does my understanding seem correct?

Thank you.

Best Wishes,
Amit.

 

>
> On Fri, Sep 16, 2016 at 8:49 PM, Eric Anderson  > 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 <
>> grp...@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+u...@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/14013c59-dc14-48d7-8521-8915c32820a9%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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/09d64ad8-cb90-498a-96c8-79626b99665e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Best practice for client channel

['Eric Anderson' via grpc.io]

On Tue, Sep 5, 2017 at 6:32 AM, Amit Saha  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