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

Question

(骆驼版本 2.14.1)

我正在尝试让 Camel 使用回退重新传送策略重试发送到 JMS（实际上是 JMS 上的 MQ）的消息。这是我得到的：

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 毫秒。在那之后骆驼将等待 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 否则超时似乎会比预期的晚发生

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

Backoff not working in Apache Camel redelivery

jms

apache-camel

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

场景 B) JMS 服务器已启动，但另一端的消费者尚未响应。

陷阱 !!!