Add new classes for eliminating xds config tears #11740
Conversation
xds/src/main/java/io/grpc/xds/XdsClusterSubscriptionRegistry.java
Outdated
Show resolved
Hide resolved
larry-safran
force-pushed
the
XdsDependencyManager
branch
from
32c80c0 to
f995211
Compare
larry-safran
force-pushed
the
XdsDependencyManager
branch
2 times, most recently
from
f5090ab to
9fcbe4c
Compare
|
Ready for review @ejona86 |
| return builder.toString(); | ||
| } | ||
|
|
||
| public String getClusterName() { |
There was a problem hiding this comment.
Why aren't the fields private if there are getters?
There was a problem hiding this comment.
Originally didn't have getters, but you are right they should be private.
There was a problem hiding this comment.
XdsClusterConfig's fields are still non-private.
| case AGGREGATE: | ||
| for (String cluster : cdsUpdate.prioritizedClusterNames()) { | ||
| CdsWatcher clusterWatcher = | ||
| (CdsWatcher) resourceWatchers.get(CLUSTER_RESOURCE).watchers.get(cluster); |
There was a problem hiding this comment.
What if this cluster is used by another aggregate cluster or used directly by the route? I think that same sort of problem could exist for EDS. Just because it isn't any more by this cluster doesn't mean it isn't used any more.
There was a problem hiding this comment.
I thought that clusters couldn't be in multiple aggregates. I started implementing a more complicated tracking of who was using a cluster, but believed that the situations you listed weren't allowed so kept it simple.
There was a problem hiding this comment.
I'm not aware of such a restriction. Look into the requirements here.
| } | ||
|
|
||
| typeWatchers.add(resourceName, watcher); | ||
| xdsClient.watchXdsResource(type, resourceName, watcher); |
There was a problem hiding this comment.
Use the 4-arg version, to pass in the executor to use (I assume syncContext). I think we would have deprecated/deleted this 3-arg version, but it is used a lot in tests. If you enter the syncContext manually within the callback, then ADS flow control stops working properly.
There was a problem hiding this comment.
You added syncContext here, but you also added syncContext.execute() to the resource watchers. That means they never will do their processing in-line. Remove the syncContext.execute() from the resource watcher callbacks.
| return clusters; | ||
| } | ||
|
|
||
| public static class XdsClusterConfig { |
| return builder.toString(); | ||
| } | ||
|
|
||
| public String getClusterName() { |
There was a problem hiding this comment.
XdsClusterConfig's fields are still non-private.
|
|
||
| XdsClusterConfig(String clusterName, CdsUpdate clusterResource, | ||
| StatusOr<EdsUpdate> endpoint) { | ||
| this.clusterName = clusterName; |
| case AGGREGATE: | ||
| for (String cluster : cdsUpdate.prioritizedClusterNames()) { | ||
| CdsWatcher clusterWatcher = | ||
| (CdsWatcher) resourceWatchers.get(CLUSTER_RESOURCE).watchers.get(cluster); |
There was a problem hiding this comment.
I'm not aware of such a restriction. Look into the requirements here.
| } | ||
|
|
||
| typeWatchers.add(resourceName, watcher); | ||
| xdsClient.watchXdsResource(type, resourceName, watcher); |
There was a problem hiding this comment.
You added syncContext here, but you also added syncContext.execute() to the resource watchers. That means they never will do their processing in-line. Remove the syncContext.execute() from the resource watcher callbacks.
…ds aggregate and eds entries.
… as recommended by code review.
larry-safran
force-pushed
the
XdsDependencyManager
branch
from
1fac607 to
3f59a16
Compare
This is just defining the XdsDependencyManager and associated classes; no movement of any functionality.