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

（驼峰版本2.14.1）

我试图让Camel使用退避重新交付策略重试msg-to-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毫秒。之后，骆驼将等待2000毫秒，然后是4000毫秒，等等，直到我们到达30000毫秒

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

为了得到我想要的结果，我可能需要在上面的代码中修改什么

TIA解决了这个问题

以下是可用的配置参数（有很多）

在错误处理程序上：

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

在URI上：

requestTimeout=400&
requestTimeoutCheckerInterval=300

这里有一些情况的表现非常不同

场景A）JMS服务器已关闭。 如果服务器关闭，则URI中的字段（

requestTimeout

和

requesttimeoutcheckenterval

）将永远不会播放。使用上述设置，您应该会看到重试延迟：500、1000、2000、4000、8000、10000、10000、10000

场景B）JMS服务器已启动，但另一端的消费者尚未响应。 requestTimeout值从不增加，但重试延迟为。因此，您将看到重试延迟：90014002400 4400840010400104001040010400

为什么?？因为它需要400毫秒（请求超时实际失败，然后errorHandler计时器启动）

哥查斯！！！

• 这是一个来自

  *MessageListenerContainer

  的日志消息：

无法刷新目标“REPLY.A.QUEUE”的JMS连接-正在使用FixedBackOff重试{interval=5000，currentAttempts=67，maxAttempts=unlimited}

这与重试消息无关，它发生在另一个线程中。那件事是在转移注意力

---

• requestTimeoutCheckerInterval

  必须始终是这只是一个偶然的机会，但是您是否尝试过

  transactionErrorHandler（）

  而不是

  defaultErrorHandler（）

  ？我没有-错误处理程序需要Spring TransactionTemplate，我在我的应用程序中没有使用它