The RetryScheduler on the query bus/gateway

[idugalic]

Enhancement Description

The RetryScheduler is capable of scheduling retries when command execution has failed. For example (as a Spring bean):

@Bean 
public CommandGateway commandGateway(CommandBus commandBus) {
        ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(5);
        RetryScheduler retryScheduler = ExponentialBackOffIntervalRetryScheduler.builder().retryExecutor(scheduledExecutorService).maxRetryCount(3).backoffFactor(1000).build();
        return DefaultCommandGateway.builder().commandBus(commandBus).retryScheduler(retryScheduler).build();
    }

It would be nice to be able to register a retry scheduler on the query gateway as well.

Current Behaviour

You are not able to register/configure a retry scheduler (retryScheduler(retryScheduler)) on the query gateway component at the moment.

Wanted Behaviour

I want to be able to register/configure a retry scheduler (retryScheduler(retryScheduler)) on the query gateway component as well.

Possible Workarounds

I am not sure if there are some good workarounds in this case.

[smcvb]

Although a RetryScheduler for the QueryGateway is a great idea, the current position of the RetryScheduler is somewhat problematic. It's a part of the org.axonframework.commandhandling. Although this doesn't make it unusable, we'd have to copy the current implementation entirely for a clean solution. Furthermore, the implementation is also CommandMessage specific, making the adjustment somewhat larger.

We could, of course, also copy the implementation, adjust it to use the Message class, and move it to a shared package. Then, we'd have to deprecate the current RetryScheduler in favor of the new implementation. All doable, but it broadens the scope quite for something that's anticipated to be relatively straightforward.

Taking all this into account combined with the outstanding issues for 4.6.0 lowers the chance that we'll introduce this issue in the upcoming minor release.

[smcvb]

Removed milestone 4.6.0 from this issue, as it's unlikely that we'll introduce it as part of the 4.6.0 release.