Open fboranek opened 8 months ago
I solve my original problem with custom ResourceVersionResolver
in Snapshot
. Now when resource list is changed the version is changed to force discovery service send response.
private static ResourceVersionResolver createVersionResolver(String version)
{
return new ResourceVersionResolver() {
@SuppressWarnings("null")
@Override
public String version(List<String> resourceNames) {
if (resourceNames.isEmpty())
return version;
var hasher = Hashing.murmur3_32_fixed().newHasher();
resourceNames.stream().forEachOrdered((name) -> hasher.putBytes(name.getBytes()));
return version + "/" + hasher.hash().toString();
}
};
}
Probably related: https://github.com/grpc/grpc-go/issues/7013#issuecomment-1972805644
Probably related: grpc/grpc-go#7013 (comment)
It's likely not. This case was there was still active connection so the resource list was not completely empty.
Whats happen was in app:
in log then i can see errors:
2024/02/13 10:56:26 E4: Problem calling: empty address list: server-2: xDS listener resource does not exist
2024/02/13 10:56:26 E4: Problem calling: empty address list: server-1: xDS listener resource does not exist
It doesn't seem as error in gRPC. Might error in control-plain library or just how I used it.
I already change it the way the gRPC like it, but still I don't know it is the right fix. Now the protocol-flow looks like:
Probably related: grpc/grpc-go#7013 (comment)
It's likely not. This case was there was still active connection so the resource list was not completely empty.
@atollena On second thought. If you using this library, the way here as in a unit test, it is exactly the same problem.
The latest gRPC library does unsubscribe resource if channel is not used and then re-subscribed. This not work properly when using
V3DiscoveryServer
withSimpleCache<>
.The question is how it should look like protocol flow in the SotW protocol variant.
Here is whats going on: 1) subscribe resource "a" and "b" 1) unsubscribe resource "b" 1) subscribe resource "a" and "b": Here library didn't response, however the xds-client already removed "b" and expecting response. If instead of re-subscribing "b" is subscribed "c", the control-plain responds.
According https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#unsubscribing-from-resources
Looks like that gRPC confirms the specification at un-subscribe.
Acording to specification https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#how-the-client-specifies-what-resources-to-return
Here i cannot tell. The resource "b" is not exactly new. It is already known resource but unsubscribed.
This unit test I used to see how it is implemented.
debug.log.txt