Does gRPC retry mechanism work and if so, where am I wrong?

[dshylov]

What version of gRPC are you using?

1.20

What did you expect to see?

I'm trying to figure out how to set up custom retry mechanism. After looking at A6-client-retries and searching through github/google I didn't find any real examples/explanations. So I think that I missed some notable thing.

So, I try to create a client connection with a retry mechanism. Like:

    Map<String, Object> retryPolicy = new HashMap<>();
    retryPolicy.put("maxAttempts", 5D);
    retryPolicy.put("initialBackoff", "10s");
    retryPolicy.put("maxBackoff", "30s");
    retryPolicy.put("backoffMultiplier", 2D);
    retryPolicy.put("retryableStatusCodes", Arrays.<Object>asList("UNAVAILABLE", "UNAUTHENTICATED"));
    Map<String, Object> methodConfig = new HashMap<>();
    Map<String, Object> name = new HashMap<>();
    name.put("service", "client");
    methodConfig.put("name", Collections.<Object>singletonList(name));
    methodConfig.put("retryPolicy", retryPolicy);
    Map<String, Object> serviceConfig = new HashMap<>();
    serviceConfig.put("methodConfig", Collections.<Object>singletonList(methodConfig));

    final NettyChannelBuilder channelBuilder = NettyChannelBuilder
        .forAddress(host, port)
        .enableRetry()
        .defaultServiceConfig(serviceConfig)
        .intercept(authInterceptor);

And client behavior doesn't change.
Could anybody get me an advice/example or move me in the right direction?

[voidzcy]

Can you make sure your service config JSON object is correct? The service name "client" does not look right. It should match the service name in proto definition.

[dapengzhang0]

@dshylov How did you test the retry behavior? Are you using authInterceptor to "deliver" a UNAUTHENTICATED trailer to the intercepted call?

[dshylov]

@voidzcy
Thanks for notation. I changed the service name on the actual service name in my proto file. But retry still not working.
@dapengzhang0 authInterceptor puts an auth token in requests. The UNAUTHENTICATED (in case if a token has expired) logic isn't yet implemented.

    Map<String, Object> retryPolicy = new HashMap<>();
    retryPolicy.put("maxAttempts", 3D);
    retryPolicy.put("initialBackoff", "10s");
    retryPolicy.put("maxBackoff", "30s");
    retryPolicy.put("backoffMultiplier", 2D);
    retryPolicy.put("retryableStatusCodes", Arrays.<Object>asList("UNAVAILABLE"));
    Map<String, Object> methodConfig = new HashMap<>();
    Map<String, Object> name = new HashMap<>();
    name.put("service", "MyServer");
    methodConfig.put("name", Collections.<Object>singletonList(name));
    methodConfig.put("retryPolicy", retryPolicy);
    Map<String, Object> serviceConfig = new HashMap<>();
    serviceConfig.put("methodConfig", Collections.<Object>singletonList(methodConfig));

    final NettyChannelBuilder channelBuilder = NettyChannelBuilder
        .forAddress(host, port)
        .enableRetry()
//        .disableServiceConfigLookUp() // the same behavior with and without it
        .defaultServiceConfig(serviceConfig)
        .intercept(authInterceptor);

[voidzcy]

@dshylov

You service name still does not look right. It should be the full name of the service, which is PROTO_FILENAME.SERVICE_NAME. For example, for the helloworld example, it should be helloworld.Greeter. I've tried with your retry config, it worked for me by using the helloworld example.

[dshylov]

@voidzcy
Thank you for help.
But a little notice, the correct way to setup is PROTO_FILE_PACKAGE_NAME.SERVICE_NAME.
However, it works with .disableServiceConfigLookUp and without. It is not yet clear to me.

[voidzcy]

@dshylov
Great to know it works for you. The reason for things working with or without .disableServiceConfigLookUp() is that you do not receive a service config in name resolution (this feature is not enabled and used externally now) so it falls back to the default service config (which is your retry config) even if you do not specify disableServiceConfigLookUp. The above is from our design perspective. For your use case, you are really aiming to use a client side service config, putting disableServiceConfigLookUp() is somewhat "semantically correct". But anyway, there is no behavior-wise difference.

[dshylov]

Thanks for the explanation @voidzcy
I will close this issue since the original problem was resolved.