2
votes

I have a Saga and the Saga sends Commands to different microservices on specific Events. Some of the microservices may be down more than others so, I want to configure a CommandGateway with a RetryScheduler and also to implement my own IntervalRetryScheduler so that I'm able to do a retry for every RuntimeException but only for some Axon Commands (this was a big help Why does the RetryScheduler in Axon Framework not retry after a NoHandlerForCommandException?).

Everything works as expected, my only concern is if there are any issues coming from the fact that some Commands will be sent with the default CommandGateway and some with my custom CommandGateway that has the custom retry built in ?

For now I would not use the custom CommandGateway even for Commands with no retry

I've gone with the distinct CommandGateway beans approach

    @Bean
    public CommandGateway commandGateway(){
        Configurer configurer = DefaultConfigurer.defaultConfiguration();
        CommandBus commandBus = configurer.buildConfiguration().commandBus();
        CommandGateway commandGateway = DefaultCommandGateway.builder().commandBus(commandBus).build();
        return commandGateway;
    }

    @Bean
    public CommandGateway commandGatewayWithRetry(){
        Configurer configurer = DefaultConfigurer.defaultConfiguration();
        CommandBus commandBus = configurer.buildConfiguration().commandBus();
        ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);
        RetryScheduler rs = IntervalRetrySchedulerImpl.builder().retryExecutor(scheduledExecutorService).maxRetryCount(5).retryInterval(1000).build();
        CommandGateway commandGateway = DefaultCommandGateway.builder().commandBus(commandBus).retryScheduler(rs).build();
        return commandGateway;
    }
1

1 Answers

2
votes

There are a couple of angles you can take from here on out.

If you are set on using the RetryScheduler/CommandGateway idea, you can do either of the following.

  • Configure distinct CommandGateway beans, either with our without the RetryScheduler
  • Be specific about the type of exception thrown from the Sagas for retries, so that your RetryScheduler can tailor towards retrying yes or no.
  • Build a Custom Command Gateway (as described here). From there on out, you can be as specific as you want when it comes to how certain commands behave.

However, I think the solution suggested in this Axon Usergroup post would be more worthwhile to follow in your situation. To summarize the suggested approach, the idea is to schedule the retry in the Saga itself by using the Deadline mechanism provided by Axon.

That way, you can just let the command fail if the microservice is unavailable (which I assume is the problem you are trying to solve) and have the Saga itself retry the operation after a certain time out.

Hope this helps you out!