Using underlying spring discovery client / ribbon to retry commands when using SpringCloudCommandRouter

Imported from Google Groups
#1

Environment:
Axon 3.2Spring boot 1.5.10
Axon distributed command bus enabled using spring-cloud

Scenario:
I’ve noticed that even though I’ve configured spring discovery-client (eureka) & ribbon to retry failing requests for services registered (zuul reverse proxy is working with retries), it seems that axon does not make use of this underlying retry infrastructure but fails immediately with:

` NoHandlerForCommandException: No node known to accept [****] `

Am I perhaps missing some additional configuration or is this facility in axon currently absent?

Thanks,
Dylan

#2

Hi Dylan,

the default retry scheduler will only retry when an exception isn’t explicitly non-transient. In this case, the NoHandlerForCommandException is a NonTransient Exception, and therefore isn’t retried.
You can extend the IntervalRetryScheduler and override the isExplicitlyNonTransient(…) method if you want to consider the NoHandlerForCommandException non-transient. In that case, Axon will happily retry these commands for a while.

Cheers,

Allard

#3

Hi Allard,

Thanks for the pointers. I implemented the solution you suggested but unfortunately it seems that NoHandlerForCommandException is not even considered for retries. I added a breakpoint inside isExplicityNonTransient(…) which is never reached when NoHandlerForCommandException is raised. As mentioned before I’m not that familiar with the framework but was hoping that somehow that the commandRouter (spring cloud in my case) would be able to delegate down to eureka retries somehow. Any other ideas or am I missing something?

Apart from the unresolved issue above I just want to point out the following to other interested parties.

  • As a side-benefit of overriding isExplicityNonTransient(…) and checking out expected business type exceptions of type RuntimeException, it no longer retries our “known” exceptions unnecessary, which is great!
  • As an improvement to IntervalRetryScheduler it would be good if log levels could be downgraded to debug level as it’s polluting our logs with unnecessary info with regards to retrying. Even better would be to not include the entire stacktrace as part of the log.

Regards,
Dylan