There is not such an option to limit number of subchannels in pick first, currently.
Using a custom resolver as sanjaypujare@ mentioned might be an option. I will note though, the c-core resolver API is not a public API nor is it stable. The best option here probably depends on how these connect attempts are failing i.e. why each connect attempt is taking so long that the sum is a problem. A few things I can think of: a) Can you limit the number of addresses in DNS records? b) Can you tune the connection timeouts? (see options for doing this in https://github.com/grpc/grpc/blob/b29c26d6b870a71a251af930a54edc97ed0d5324/include/grpc/impl/codegen/grpc_types.h#L262) c) If a certain set of address consistently fails to connect (e.g. IPv6 addresses or IPv4 addresses), can you, for example, configure routing tables in order to make connect attempts to those addresses fail fast? thanks, Alex On Wednesday, May 25, 2022 at 1:13:01 PM UTC-7 [email protected] wrote: > You may consider creating a custom resolver (or extend the current ares > resolver) to limit the number of addresses returned. > > On Sunday, May 22, 2022 at 7:11:39 AM UTC-7 [email protected] wrote: > >> Thanks for the reply; I wanted to verify there wasn't some method that I >> wasn't aware of. >> It's a simple enough option to add and evaluate when creating the >> PickFirstSubchannelList. >> >> I'm using the pick_first load balancer since I only want one subchannel >> connected at any one time. >> I want to limit the number of subchannels attempted by pick_first so that >> a channel fails to TRANSIENT_FAILURE state faster if a smaller subset of >> subchannels fail. >> >> On Friday, May 20, 2022 at 11:26:06 AM UTC-7 [email protected] wrote: >> >>> > Is there a method or option to limit the number of subchannels created >>> to be fewer than the number of addresses resolved by ares? >>> >>> First, are you trying to limit the number of subchannels created, or the >>> number of connections created? (note, a subchannel data structure takes >>> some memory of course but does not necessarily have an active TCP >>> connection associated with it). >>> >>> We don't have an option for limiting the number of subchannels. However, >>> we do have a concept of load balancing policy (also see >>> https://github.com/grpc/grpc/blob/master/doc/load-balancing.md#:~:text=The%20gRPC%20client%20supports%20an,and%20managing%20their%20connectivity%20behavior), >>> >>> which can be used as a coarse grained knob for configuring the number of >>> active connections that a channel will have open. >>> >>> Some key points: >>> - if you're using the pick_first load balancing policy (the default >>> one), then the channel will try to maintain just one connection at a time, >>> no matter how many addresses were resolved >>> - if you're using the round_robin policy, then the channel will try to >>> maintain one connection to each address that was resolved >>> - there are other LB policies using lookaside load balancers linked to >>> from >>> https://github.com/grpc/grpc/blob/master/doc/load-balancing.md#:~:text=The%20gRPC%20client%20supports%20an,and%20managing%20their%20connectivity%20behavior >>> >>> >>> >>> On Monday, May 16, 2022 at 10:22:41 AM UTC-7 [email protected] wrote: >>> >>>> Hi, >>>> >>>> Is there a method or option to limit the number of subchannels created >>>> to be fewer than the number of addresses resolved by ares? >>>> >>>> Is there anything in the execution chain: ares resolver -> server >>>> address list -> address sorting -> subchannel list creation that can >>>> ultimately reduce the # of subchannels created? >>>> >>>> Regards, >>>> Peter Hurley >>>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5ab391e4-d582-4f79-927c-279fd3fe6d0en%40googlegroups.com.
