1

I'm using JHipster version 4.6.2 on my gateway. I have a JHipster registry and two instances of the same microservice. In the JHipster registry I can see that the gateway and both microservice instances are registered properly. I can configure, see health and so on. In short all is working fine.

The microservice was created with a newer JHipster version (4.11.1). Both the gateway and microservices seem to co-operate well. For example the default (generated) user interface on gateway is capable to fetch data (entities) from microservices. On gateway I just use the logic that Jhipster generated for me to fetch data from microservice. I can see in the logs that calls are routed to both microservice instances.

The issue that I'm facing is that when I shutdown one microservice instance the gateway still sometimes tries to route the the service call to the microservice instance that is already shutdown. Of course after some time all service calls are routed properly just to the correct/running microservices instance. But sometimes right after shutting down one microservices instance the call might be routed to the "wrong" instance.

I expected that components like ribbon, zuul and eureka would automatically try other microservice instance if the service call to the first microservice instance fails. Is my expectation correct? Should Jhipster "microservices platform" automatically retry the service call against other registered microservice instance?

If by default retrying is not supported, what should I do to make it happen?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Jussi Seppälä
  • 76
  • 9
  • You must configure it in application properties of the gateway because this is not enabled by default by spring cloud. The spring cloud doc is not very easy but you can configure different strategies per zuul route, see https://stackoverflow.com/questions/42651456/spring-cloud-zuul-retry-when-instance-is-down-and-forward-to-other-available-ins – Gaël Marziou Dec 15 '17 at 21:27
  • Do you have solution . – csu May 14 '18 at 11:57

1 Answers1

1

Thanks for your response Gael. I tried configuration from the link you provided but that did not fully solve my case.

When managed to get rid of the original exception ("com.netflix.client.ClientException: null") I faced the next issue ("Caused by: com.netflix.client.ClientException: Number of retries on next server exceeded max 2 retries, while making a call for: 192.168.1.4:8082"). I needed to adjust MaxAutoRetriesNextServer (see https://github.com/spring-cloud/spring-cloud-netflix/issues/2052). That brought me one step further but still got hystrix exceptions ("Caused by: com.netflix.hystrix.exception.HystrixRuntimeException: myservice timed-out and no fallback available.").

Finally with help of these two links (https://github.com/jhipster/generator-jhipster/issues/3323 and https://github.com/spring-cloud/spring-cloud-netflix/issues/321) I managed to make configuration which has been providing 100% availability in my tests (so far).

This is the configuration that has worked for me. I don't fully know all details behind all these settings so if you find any inconsistencies in those or you have suggestions for improvements please raise them up. Thanks!

zuul:
    routes:
        myservice:
            retryable: true
    host:
        connect-timeout-millis: 5000
        socket-timeout-millis: 20000            
ribbon:
    MaxAutoRetries: 1
    MaxAutoRetriesNextServer: 5
    OkToRetryOnAllOperations: true
    ReadTimeout: 2500
    restclient:
        enabled: true
hystrix:
    command:
        default:
            execution:
                isolation:
                    thread:
                        timeoutInMilliseconds: 20000
Jussi Seppälä
  • 76
  • 9