spring-cloud with RestTemplate//Ribbon/Eureka - retry when server not available

3
votes

I managed to successfully get my RestTemplate client discover remote service using Eureka and forward calls to it using Ribbon as described in the documentation. Basically, it was just a matter of adding the following annotations of my Application class and let the magic of Spring-Boot do the rest:

@Configuration
@ComponentScan
@EnableAutoConfiguration
@EnableDiscoveryClient

(PS: you noticed I'm using spring-cloud:1.0.0-SNAPSHOT-BUILD and not 1.0.0.M3 - but this doesn't seem to affect my problem).

When two service instances are started, the rest-template client successfully load balance requests between the two. However, the client won't fallback to the second instance if the first is stopped before the Eureka load balancer notices, instead an exception is thrown.

Hence my question: is there a way to configure the RestTemplate/Ribbon/Eureka stack to automatically retry the call to another instance if the one selected the first place is not available? Zuul proxy and feign clients do this "out of the box" so I believe the library holds the necessary features...

Any idea/hint?

Thx, /Bertrand

2
netflixspring-cloud
Or is it because the integration into the RestTemplate is done using an interceptor whose only purpose is to translate the serviceId into an appropriate URL but doesn't wrap the entire call process and therefore is not able to perform any "retry" logic ? – Bertrand Renuart

2 Answers

4
votes

The RestTemplate support on its own does not know how to do any retrying (whereas the Feign client and the proxy support in Spring Cloud does, as you noticed). I think this is probably a good things because it gives you the option to add it yourself. For instance, using Spring Retry you can do it in a simple declarative style:

@Retryable
public Object doSomething() {
   // use your RestTemplate here
}

(and add @EnableRetry to your @Configuration). It makes a nice combination with @HystrixCommand (from Spring Cloud / Javanica):

@HystrixCommand
@Retryable
public Object doSomething() {
   // use your RestTemplate here
}

In this form, every failure counts towards the circuit breaker metrics (maybe we could change that, or maybe it makes sense to leave it like that), even if the retry is successful.

0
votes

I couldn't get it to work with both @HystrixCommand and @Retryable, regardless of order of annotations on @Configuration class or on @Retryable method due to order of interceptors. I solved this by creating another class with the matching set of methods and had the @HystrixCommand annotated methods delegate to the corresponding @Retryable method in the second class. You could probably have the two classes implement the same interface. This is kind of a pain in the butt, but until order can be configured, this is all I could come up with. Still waiting on a real solution from Dave Syer and the spring cloud guys.

public class HystrixWrapper {
    @Autowired
    private RetryableWrapper retryableWrapper;

    @HystrixCommand
    public Response doSomething(...) {
        return retryableWrapper.doSomething(...);
    }
}

public class RetryableWrapper {
    @Autowired
    private RestTemplate restTemplate;

    @Retryable
    public Response doSomething(...) {
        // do something with restTemplate;
    }
}