core, grpclb: change policy selection strategy for Grpclb policy (take two: move logic of querying SRV into Grpclb's own resolver) #6723
…, service config, balancer addresses. Subclass is able to override the resolve logic.
…r will provide GrpclbNameResolver directly. This also eliminate the enableSrv flag.
I use the
Having to use
EDIT: Or am I miss-reading this PR and it turns dns+srv on by default?
This PR is part of the implementation for https://github.com/grpc/proposal/blob/master/A26-grpclb-selection.md. The previous part is #6637. I updated the title of this PR.
We are eliminating the usage of SRV records other than in gRPCLB. Previously, this is special logic in grpc-core for gRPCLB's design. The system variable
How do you use SRV records? Did you implement a special way to use SRV resolved addresses? We expect SRV records are for remote balancer addresses. This is true in existing grpc-core as SRV resolved addresses are tagged with
For your case, I believe you would need to implement your own DNS-based name resolver as you are exploiting the internal implementation of
@ST-DDT, in 1.25.0 we added a dns name resolver to the
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…e two: move logic of querying SRV into Grpclb's own resolver) (grpc#6723) Eliminated the code path of resolving Grpclb balancer addresses in grpc-core and moved it into GrpclbNameResolver, which is a subclass of DnsNameResolver. Main changes: - Slightly changed ResourceResolver and its JNDI implementation. ResourceResolver#resolveSrv(String) returns a list of SrvRecord so that it only parse SRV records and does nothing more. It's gRPC's name resolver's logic to use information parsed from SRV records. - Created a GrpclbNameResolver class that extends DnsNameResolver. Logic of using information from SRV records to set balancer addresses as ResolutionResult attributes is implemented in GrpclbNameResolver only. - Refactored DnsNameResolver, mainly the resolveAll(...) method. Logics for resolving backend addresses and service config are modularized into resolveAddresses() and resolveServiceConfig() methods respectively. They are shared implementation for subclasses (i.e., GrpclbNameResolver).