fundo

Estou usando o Spring cloud Brixton.RC2, com Zuul e Eureka.

Eu tenho um serviço de gateway com@EnableZuulProxy e umbook-service com umstatus método. Através da configuração eu posso emular o trabalho nostatus método, adormecendo uma quantidade de tempo definida.

A rota Zuul é simples

zuul.routes.foos.path=/foos/**
zuul.routes.foos.serviceId=reservation-service

Eu corro duas instâncias dobook-service. Quando defino o tempo de suspensão abaixo do limite de tempo limite do Hystrix (1000ms), vejo solicitações indo para as duas instâncias dos serviços de livros. Isso funciona bem.

Problema

Entendo que, se o comando Hystrix falhar, será possível que o Ribbon tente novamente o comando em um servidor diferente. Isso deve tornar a falha transparente para o cliente.

Eu li a configuração da faixa de opções e adicionei a seguinte configuração no Zuul:

zuul.routes.reservation-service.retryable=true //not sure which one to try
zuul.routes.foos.retryable=true //not sure which one to try

ribbon.MaxAutoRetries=0 // I don't want to retry on the same host, I also tried with 1 it doesn't work either
ribbon.MaxAutoRetriesNextServer=2
ribbon.OkToRetryOnAllOperations=true

Agora, atualizo a configuração para que apenas um serviço durma por mais de 1s, o que significa que eu tenho um serviço de integridade e um ruim.

Quando eu chamo os gateways, as chamadas são enviadas para as duas instâncias e metade das chamadas retorna 500. No gateway, vejo o tempo limite do Hystrix:

com.netflix.zuul.exception.ZuulException: Forwarding error
    [...]
Caused by: com.netflix.hystrix.exception.HystrixRuntimeException: reservation-service timed-out and no fallback available.
    [...]
Caused by: java.util.concurrent.TimeoutException: null

Por que a fita não está tentando novamente a chamada na outra instância?

Estou faltando alguma coisa aqui?

ReferênciasRelaciona-se a issoPergunta, questão (não resolvido)Configuração da faixa de opçõesDe acordo com issocometer, entregar Zuul deve oferecer suporte a novas tentativas para Ribbon