Add XdsClient implementation of watching LDS/RDS resources, replacing the ConfigWatcher API. This makes LDS/RDS/CDS/EDS resource watchers work similarly. This change also cleans up XdsClientImpl's tests.
Normally the first exception/event experienced is the cause and is
followed by a stampede of ClosedChannelExceptions. In this case,
SslHandler is manufacturing a ClosedChannelException of its own and
propagating it _before_ the trigger event. This might be considered a
bug, but changing SslHandler's behavior would be very risky and almost
certainly break someone's code.
Fixes#7376
Unary are far more common than streaming, and we're throwing for unary even
though it doesn't help the service. Let's stop doing that. We also stop
throwing in onComplete() for all cases, because it doesn't help any service;
it doesn't stop the service's processing and isn't even all that informative
since the cancellation can happen even after onComplete() is called.
`RlsPicker.pickSubchannel()` does not run in SynchronizationContext, but it calls `CachingRlsLbClient.get()` which assumed running in SynchronizationContext. Fixed by removing `synchronizationContext.throwIfNotInThisSynchronizationContext()`. `CachingRlsLbClient.get()` is actually thread-safe in the sense it's guarded by lock, and `DataCacheEntry`'s fields are final.
`ChildPolicyWrapper.picker` was not thread-safe. Fixed by making it volatile.
Changed the test a bit since the old test doesn't really test things well.
It's hoped that this resolves the "too_many_pings" issue some users are
seeing that is worked around by GRPC_EXPERIMENTAL_AUTOFLOWCONTROL=false.
This change also avoids resetting the ping count for empty data frames
(which shouldn't really happen with gRPC).
The previous code failed to reset the ping count on HEADERS and
WINDOW_UPDATE. The code _appeared_ to have callbacks for WINDOW_UPDATE,
but was layered above the Http2Connection so was never called. Thus,
this version is much more aggressive then the previous version while
also addressing the correctness issue.
It deprecates ExpectedException and Assert.assertThat(T, org.hamcrest.Matcher).
Without Java 8 we don't want to migrate away from ExpectedException at
this time. We tend to prefer Truth over Hamcrest, so I swapped the one
instance of Assert.assertThat() to use Truth. With this change we get a
warning-less build with JUnit 4.13. We don't yet upgrade because we
still need to support JUnit 4.12 for some use-cases, but will be able to
upgrade to 4.13 soon when they upgrade.
Introduce ResourceSubscriber for tracking the state of a single resource.
Every time newly subscribing to some resource, a corresponding ResourceSubscriber is created. Note it does not control the resource discovery RPCs. It is still the XdsClient that sends RPCs for with all subscribed resource names for each type. A ResourceSubscriber can have the following states:
- When the initial resource fetch timer (respTimer) is pending, the resource is under discovery, the resource data is unknown. Even if the XdsClient receives a response not containing the corresponding resource, it does not mean the resource is absent. We still need to wait until a response containing the resource data coming or the timer being fired. The timer is scheduled when the ResourceSubscriber is created. So the XdsClient should always create the corresponding ResourceSubscriber when it starts to subscribe a new resource.
- If the resource fetch timer is not pending, we must know the existence of the resource data. If data field is set, it is the most recently received resource data (aka, cached entry). Otherwise, absent field is set to true, indicating the resource does not exist. The exceptional case is when the ADS stream is closed and in the retry backoff period. During that period, respTimer is cancelled and the resource existence may or may not be known. Once the backoff finishes, the XdsClient will reschedule the respTimer when it recreates the ADS stream and re-request all the resources.
Watchers can be added to existing ResourceSubscribers. At the time the watcher is added, its callback will be invoked if we've already known the existence of the resource. Otherwise, the watcher will just sit there and wait data or absence to come in the future.
The PROXYLESS_CLIENT_HOSTNAME node metadata was a temporary workaround for management server to not send back all backend services as load reporting clusters. Now the management server is able to use `send_all_clusters` field to let the client side decide the group of clusters it is reporting loads for. So this node metadata is no longer needed.
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.
Chengyuan Zhang
Eric Anderson
ZHANG Dapeng
Ran
sanjaypujare
Sergii Tkachenko
Russell Shaw
Esun Kim