Description
I have a consumer service calling an provider service which is running with 2 instances.
The provider interface
@FeignClient("example")
public interface ExampleService {
@RequestMapping(
method = {RequestMethod.POST},
value = {"/greeting/{nameToGreat}"}
)
String greeting(@PathVariable(value = "nameToGreat") String nameToGreat);
The ribbon configuration within the consumer service is as follows:
example.ribbon.OkToRetryOnAllOperations=false
example.ribbon.ReadTimeout=3999
example.ribbon.MaxAutoRetries=0
example.ribbon.MaxAutoRetriesNextServer=3
If there is a SocketTimeoutException during a call to the example service, I would not expect that there a retry to the next instance occurs, because POST requests are not idempotent.
But the real behavior is that there retries to the next instance occurs which causes creation of duplicate accounts aso.
In a debugging session I could see that a correct RequestSpecificRetryHandler with the ribbon config values from above will be created and as far I could see the method isRetriableException(...) of that handler returns false.
What can I do to find a solution?
Thanx
Lutz
Activity
LutzStrobel commentedon Jul 29, 2015
Now I found that the FeignClient uses the default retryer which retries the failed requests on its own.
I think this is not desired, because it overrules the configuration for the ribbon loadbalancer.
Maybe this is not a feature, is it?
Lutz
[-]LoadBalancerCommand retries post requests even if configured: OkToRetryOnAllOperations=false[/-][+]Feign Retryer is not configurable and overlaps with the ribbon retry.[/+]spencergibb commentedon Mar 3, 2016
Perhaps the default should be an empty
Retryer
.As a workaround, you can create a
Retryer
bean in a Feign Client Configuration.padilo commentedon Apr 25, 2016
Workaround works like a charm:
srowatt commentedon Apr 6, 2017
There's a NEVER_RETRY implementation so you can do
@Bean public Retryer retryer() { return Retryer.NEVER_RETRY; }
ryanjbaxter commentedon Apr 6, 2017
We can close this issue because all this retry logic was simplified in the latest Camden SRs and and Dalston snapshots and there is only one level of retry now.
theknickerbocker commentedon Jul 18, 2017
Can you explain what you mean by 'there is only one level of retry now'?
spencergibb commentedon Jul 18, 2017
We've eliminated the feign retry with our ribbon retry