-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify how re-subscribing to resources should work #339
Comments
I solve my original problem with custom 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: 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:
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: |
@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:
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
The text was updated successfully, but these errors were encountered: