Change XdsClient to support multiple LDS and RDS watchers#23938
Conversation
|
This is now ready for review. |
donnadionne
left a comment
There was a problem hiding this comment.
Reviewed 4 of 9 files at r1, 5 of 5 files at r2.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @markdroth)
src/core/ext/xds/xds_api.cc, line 347 at r2 (raw file):
// If the same best matched domain pattern appears in multiple virtual hosts, // the first matched virtual host wins. VirtualHost* target_vhost = nullptr;
why not keep the const?
src/core/ext/xds/xds_api.cc, line 352 at r2 (raw file):
// Check each domain pattern in each virtual host to determine the best // matched virtual host. for (VirtualHost& vhost : virtual_hosts) {
why not keep the const?
src/core/ext/xds/xds_api.cc, line 1755 at r2 (raw file):
grpc_error* error = RouteConfigParse(client, tracer, route_config, &rds_update); if (error != GRPC_ERROR_NONE) return error;
The logic here changed a bit: if there is a parsing error, the entry is still already added to rds_update_map; whereas before it's only added after parsing is successful.
This is true for Route, and Cds and Eds below
src/core/ext/xds/xds_client.cc, line 908 at r2 (raw file):
} // Ignore identical update. ListenerState& listener_state = xds_client()->listener_map_[listener_name];
use fine here? so we don't add an entry with no value?
src/core/ext/xds/xds_client.cc, line 983 at r2 (raw file):
} RouteConfigState& route_config_state = xds_client()->route_config_map_[route_config_name];
use find?
src/core/ext/xds/xds_client.cc, line 1105 at r2 (raw file):
} EndpointState& endpoint_state = xds_client()->endpoint_map_[eds_service_name];
use find?
markdroth
left a comment
There was a problem hiding this comment.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @donnadionne)
src/core/ext/xds/xds_api.cc, line 347 at r2 (raw file):
Previously, donnadionne wrote…
why not keep the const?
Making this method return non-const allows us to use std::move() in xds_resolver.cc line 517.
src/core/ext/xds/xds_api.cc, line 352 at r2 (raw file):
Previously, donnadionne wrote…
why not keep the const?
See above.
src/core/ext/xds/xds_api.cc, line 1755 at r2 (raw file):
Previously, donnadionne wrote…
The logic here changed a bit: if there is a parsing error, the entry is still already added to rds_update_map; whereas before it's only added after parsing is successful.
This is true for Route, and Cds and Eds below
That's true, but it doesn't matter, because the result will be ignored when we return an error anyway.
src/core/ext/xds/xds_client.cc, line 908 at r2 (raw file):
Previously, donnadionne wrote…
use fine here? so we don't add an entry with no value?
The entry will always already exist at this point, because XdsApi::ParseAdsResponse() won't return any resources that we are not subscribed to.
src/core/ext/xds/xds_client.cc, line 983 at r2 (raw file):
Previously, donnadionne wrote…
use find?
See above.
src/core/ext/xds/xds_client.cc, line 1105 at r2 (raw file):
Previously, donnadionne wrote…
use find?
See above.
65de07e to
af44750
Compare
af44750 to
5acae9f
Compare
donnadionne
left a comment
There was a problem hiding this comment.
Reviewable status: 6 of 9 files reviewed, all discussions resolved (waiting on @donnadionne)
|
The "Basic Tests Python Windows" failure is an infrastructure timeout. |
Instead of having one special watcher instance for combined LDS/RDS data that has the same lifetime as the XdsClient, we now provide the same type of watcher API for LDS and RDS as we already have for CDS and EDS.
This provides a cleaner separation of concerns between the XdsClient and its watchers: the XdsClient deals exclusively with the transport protocol, and the watchers deal with the data model.
This paves the way for future changes that will (a) add xDS support in the gRPC server and (b) share a single XdsClient instance between channels.
This change is