Mule ESB：如何在MULE ESB中实现典型的重试机制答案

【问题标题】：Mule ESB: How to achieve typical ReTry Mechanism in MULE ESBMule ESB：如何在MULE ESB中实现典型的重试机制
【发布时间】：2014-11-01 05:40:50
【问题描述】：

我需要在重试上实现一个逻辑。入站端点将消息推送到 Rest（出站）。如果 REST 不可用，我需要重试 1 次并将其放入队列中。但是第二个即将到来的消息不应该做任何重试，它必须直接将消息放入队列，直到 REST 服务可用。

一旦服务可用，我需要通过批处理作业将所有消息从 QUEUE 推送到 REST 服务（按顺序）。

问题：

我如何知道第二条消息的服务不可用？如果我使用直到成功，对于每条消息，它都会重试并放入队列。 Plm 是第二条消息，不应重试。
对于批处理，我想到了使用轮询，但如何告诉轮询，何时服务可用以开始批处理。（bcz，Poll 更多的是配置运行批处理的时间）？
让我感到困惑的其他问题是 - 此处必须保留订单。一旦服务可用。队列消息（即批处理）必须首先移动到 REST 服务，然后才能实时移动。我怀疑它是否适用。

对快速响应实现逻辑很有帮助。

使用骡子：3.5.1

【问题讨论】：

【解决方案1】：

我可以尝试以下方法：使用流控制

处理消息；如果出现异常或错误的响应代码，请设置一个变量/属性，例如 serviceAvailable=false。
后续消息处理会先检查属性serviceAvailable来处理消息。如果属性为 false，则将消息排队到状态=新/未处理的数据库表中
创建一个流/调度程序来按顺序处理来自数据库的消息，但它不会检查属性 serviceAvailable 并调用其余服务。如果服务抛出异常，它将不会再次将消息存储在数据库中，但如果进程成功更改属性 serviceAvailable=true 并将消息出队或更改状态。如果 db 表中有更多消息，例如 moreDBMsg=true，则添加另一个属性并将其设置为 true。在 moreDBMsg=false 之前，不应处理/消费新消息再一次 DBMsg=false 和 serviceAvailable=true 开始处理来自队列的消息。

【讨论】：

感谢您的光 :)。这对我很有帮助。我正在尝试执行上述过程。在这里我有一个疑问，如果我在属性或会话变量中设置属性 serviceAvaialble = false。做第二个新交易能够看到我在 mule 流中为第一个交易设置的变量（bcz 我相信所有属性都已删除，并且属性对于即将发生的交易应该是新的）。如果是这种情况，我如何将属性设置为对所有即将发生的事务全局可见？请建议。提前致谢

【解决方案2】：

对于超时，我仍然会查看响应代码并捕获超时以确定调用是成功还是需要重试。实际上，无论如何您通常都会进行多线程处理，因此无论如何您都有多个并行调用。或者只是一个电话在另一个电话结束之前开始。这很正常。

但是您可以简单地在超时的队列中重试呼叫。在 x 次超时后，您“跳过”或推迟重试。

但所有这些都是使用实际的 Mule 流组件完成的，例如：

队列的一种可能性是将其保存在数据库中。 Mule 的数据库连接器具有“轮询”功能，请参阅：http://www.mulesoft.org/documentation/display/current/JDBC+Transport+Reference#JDBCTransportReference-PollingTransport

【讨论】：