Sync Envoy proto to commit fd28e42f31730f5ed6f13f52999692a4885dd312 (2020-09-15, internal Envoy import CL: cl/332279092). Suppressed warning for using listening_addresses in Node and added TODO for cleaning it up.
Updated protobuf gradle plugin version to 0.8.13. Fixed Android Kokoro's memory issue by forcing to use a new Gradle daemon for building the previous commit.
Create the xDS channel outside the XdsClient. Throw an XdsInitializationException if the provided server list (parsed from the bootstrap file) can not be used to create such a channel. The exception is caught by the xDS resolver and propagated to the Channel gracefully as a name resolution error.
Implemented the new EDS LB policy, which generates a LB config for instantiating a hierarchical load balancing subtree. The subtree includes downstream LB policies:
- priority LB policy, which load balances individual priorities separately
- weighted-target LB policy, which load balances individual localities within the same priority separately
- lrs LB policy, which applies load recording that aggregates load stats for each locality
- leaf LB policy (round_robin)
The EDS LB policy is the place that receives endpoint information from traffic director and organizes the data into a model for hierarchical load balancing for the cluster.
An issue was found during CBT RLS client testing: The RLS lb creates grplb child balancer, calls `grpclb.handleResolvedAddress()` then immediately calls `grpclb.requestConnection()`. The subchannel in `GrpclbState.currentPicker.pickList` contains only `GrpclbState.BUFFER_ENTRY` at the moment `grpclb.requestConnection()` is called, and therefore the `requestConnection()` is no-op, and RPC is hanging.
The version_info in the xDS protocol represents the client's knowledge for the state of that resource type. It should persist across ADS stream recreation. Even if the ADS stream is recreated, the XdsClient should persist its knowledge for resources it has received. With this implementation, client and server are stateful across the xDS communication. With persisted version_info, the management server knows resources that the client currently knows even after the stream is recreated. So it does not need to re-send resources that the client received with the previous stream.
This is a very simple change to test for IBMJSSE2 security provider in addition to the others. IBM JRE does not support the Sun provider, but instead has IBMJSSE2 which supports the same API calls.
I tested this on Z/OS machine as now it works when before it couldn't find a security provider
Introduce XdsInitializationException, which is thrown when gRPC fails to read the xDS bootstrap information, or fails to create the XdsClient object with loaded bootstrap configurations. gRPC components (e.g., the XdsNameResolver) is expected to propagate such exceptions gracefully to the channel.
As mentioned in https://github.com/grpc/grpc-java/pull/7413#issuecomment-690756200 `RealChannel` did not manage `configSelector`, and therefore `configSelector.get()`, `configSelector.set()` and `drainPendingCalls()` were scattered everywhere in `ManagedChannelImpl`. This PR re-organizes `RealChannel` to manage `configSelector`.
Fixing the bug: if two consecutive name resolution updates are queued together in SynchronizationContext, drainPendingCalls() might be called twice and be broken.
There was bug that new pending calls were not drained after channel is shutdown. The bug was worked around by #7354 .
Fixing by making sure new calls fail immediately if the channel is already shutdown.
96ad6338 accidentally caused the javadoc and sources jars to no longer
be published for grpc-netty-shaded. It would appear to be due to the
jars being empty. This commit causes them to be published again.
Eliminated the logic in CDS LB policy that handles CDS config change (aka, cluster name change). A CDS LB policy should be used for a single cluster, the cluster should be effectively final. If the upstream LB policy needs to change routing cluster, it should create separate CDS LB policies, one for each cluster.
This change also reimplemented the unit tests for CDS LB policy.
Now that routing is enabled by default, we should always generate a load balancing config that uses xds_routing as the top-level LB policy. This change is made to the legacy xDS resolver, which will soon be replaced by XdsNameResolver2. But this change allows us to merge split codepath for CDS LB policy.