为什么在NoHandlerForCommandException之后Axon Framework中的RetryScheduler不重试? [英] Why does the RetryScheduler in Axon Framework not retry after a NoHandlerForCommandException?

查看:96
本文介绍了为什么在NoHandlerForCommandException之后Axon Framework中的RetryScheduler不重试?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我有一个Saga,Saga在特定事件上向不同的微服务发送命令.我想使用RetryScheduler配置commandGateway,以便在其他微服务关闭时重试发送命令. RetryScheduler仅在异常是RuntimeException的情况下才执行重试,该异常是在其他服务(如果确实是脱机)时抛出的NoHandlerForCommandException.

so I have a Saga and the Saga sends a command to a different microservice on a specific event. I wanted to configure the commandGateway with a RetryScheduler, so that it retries to send the command in case that the other microservice is down. The RetryScheduler will only perform retries if the exception is a RuntimeException, which the NoHandlerForCommandException that is thrown when the other service if offline definately is.

如果我未设置maxRetryCount,则错误消息为
o.a.c.gateway.IntervalRetryScheduler:处理命令[XXXCommand]导致异常1次.永久放弃

If i dont set the maxRetryCount then the error message is
o.a.c.gateway.IntervalRetryScheduler : Processing of Command [XXXCommand] resulted in an exception 1 times. Giving up permanently

如果我确实设置了属性,则错误消息为
o.a.c.gateway.IntervalRetryScheduler:处理命令[XXXCommand]会导致异常,并且不会重试

If I do set the attribute the error message is
o.a.c.gateway.IntervalRetryScheduler : Processing of Command [XXXCommand] resulted in an exception and will not be retried

如果另一个微服务正在运行,则该命令已正确处理,没有问题.

If the other microservice is running, then the command is handled correctly, no problems.

有人知道可能是什么问题吗?

Does anybody have an idea what could be the issue?

这是我对带有RetryScheduler的commandGateway的配置:

This is my configuration for the commandGateway with a RetryScheduler:

@Bean
public CommandGateway commandGateway(){

    Configurer configurer = DefaultConfigurer.defaultConfiguration();

    CommandBus commandBus = configurer.buildConfiguration().commandBus();

    ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);
    RetryScheduler rs = IntervalRetryScheduler.builder().retryExecutor(scheduledExecutorService).maxRetryCount(100).retryInterval(1000).build();
    CommandGateway commandGateway = DefaultCommandGateway.builder().commandBus(commandBus).retryScheduler(rs).build();

    return commandGateway;
}

推荐答案

要解决当前的问题,您可以提供自己的IntervalRetryScheduler实现,该实现将覆盖IntervalRetryScheduler#isExplicitlyNonTransient(Throwable)方法,以考虑重试NoHandlerForCommandException.

To resolve the problem at hand, you could provide your own implementation of the IntervalRetryScheduler, which overrides the IntervalRetryScheduler#isExplicitlyNonTransient(Throwable) method to also take into account retrying the NoHandlerForCommandException.

请注意,尽管IntervalRetryScheduler有意仅对类型为AxonNonTransientException的异常进行重试,但通常会发出可恢复异常的信号. NoHandlerForCommandException表示正在使用的CommandBus实现也不知道该向谁提供命令,这通常暗示着无法重试的事情.

Note though that the IntervalRetryScheduler is intentionally only retrying on exceptions which are of type AxonNonTransientException, is those typically signal recoverable exceptions. The NoHandlerForCommandException means that the CommandBus implementation being used has no clue whom to give the command too, something which in general suggests an thing which cant be retried.

但是,看来您有一个确实可行的方案.因此,就像我一开始指出的那样,重写isExplicitlyNonTransient(Throwable)方法以排除NoHandlerForCommandException是我认为适合您的方法.

It however seems you have a scenario where it does make sense. Thus, like I point out at the start, overriding the isExplicitlyNonTransient(Throwable) method to exclude NoHandlerForCommandException would be the way to go for you I think.

希望这对您有所帮助!

这篇关于为什么在NoHandlerForCommandException之后Axon Framework中的RetryScheduler不重试?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆