jms - 退避在 Apache Camel 重新交付中不起作用

Question

( Camel 版本 2.14.1)

我正在尝试让 Camel 使用回退重新传递策略重试向 JMS(实际上是 MQ over JMS)发送消息。这是我所拥有的:

errorHandler(defaultErrorHandler()
    .maximumRedeliveries(-1) 
    .useExponentialBackOff()
    .backOffMultiplier(2)
    .maximumRedeliveryDelay(30000)
    .retryAttemptedLogLevel(LoggingLevel.WARN));

from("direct:in")
    .log("Sending message to MQ")
    .to("mq:MY_QUEUE?requestTimeout=1000");

我对这里应该发生什么的理解是初始超时将是 1000 毫秒。在那之后， Camel 将等待 2000 毫秒，然后是 4000 毫秒，依此类推，直到我们达到 30000 毫秒。

发生的事情是消息被重试，但每次都是 1000 毫秒。

我可能需要在上面的代码中进行哪些更改才能获得我正在寻找的结果？

TIA

Answer 1

想通了这一点。

以下是可用的配置参数(有很多)。

在错误处理程序上:

defaultErrorHandler()
    .maximumRedeliveries(-1) 
    .useExponentialBackOff()
    .backOffMultiplier(2)
    .maximumRedeliveryDelay(10000)
    .redeliveryDelay(500)

在 URI 上:

requestTimeout=400&
requestTimeoutCheckerInterval=300

这里有一些场景的行为非常不同

场景 A) JMS 服务器已关闭。

如果服务器关闭，那么来自 URI 的字段( requestTimeout 和 requestTimeoutCheckerInterval )永远不会发挥作用。使用上面的设置，您应该会看到重试延迟:500、1000、2000、4000、8000、10000、10000、10000...

场景 B) JMS 服务器已启动，但另一端的使用者没有响应。

requestTimeout 值永远不会增加，但重试延迟会增加。所以你会看到重试延迟: 900, 1400, 2400, 4400, 8400, 10400, 10400, 10400....

为什么？因为它需要 400 毫秒( requestTimeout 实际失败，之后 errorHandler 计时器启动)。

问题!!!

这是来自 *MessageListenerContainer 的日志消息。 :

Could not refresh JMS Connection for destination 'REPLY.A.QUEUE' - retrying using FixedBackOff{interval=5000, currentAttempts=67, maxAttempts=unlimited}
这与重试消息无关，它发生在另一个线程中。那个 FixedBackOff事情是一个红鲱鱼。

requestTimeoutCheckerInterval必须始终 <= requestTimeout否则超时似乎会比预期的要晚