2

我已经或多或少地在我的 Mule 应用程序中使用持久性 VM 队列 CloudHub 实现了可靠性模式，如此处所述。虽然一切正常，但它给我留下了许多关于实际确保可靠传递我的消息的问题。为了说明以下几点，假设我http-request的“应用程序逻辑流”（参见上面链接上的图表）中有组件由于端点关闭而引发异常，并且我想确保飞行中的消息最终会得到传送到端点：

  1. 正如上面链接中所详述的，我观察到，当在我的“应用程序逻辑流”中引发异常时，并且我已将流设为事务性，消息将放回 VM 队列中。然而，所发生的只是消息反复从队列中取出，由流处理，然后再次抛出异常 - 无限。似乎无法在 VM 队列上配置任何类型的重试延迟或最大重试次数，例如使用 ActiveMQ。我想出的最好的解决方法是http-request用范围包围消息处理器until-successful，但我宁愿让这些东西适用于我的整个流程（不必将整个流程包装在 中until-successful）。仅使用 VM 队列和 CloudHub 可以实现这种事情吗？
  2. 我已将我配置until-successful为将消息放在另一个我想用作死信队列的 VM 队列上。同样，这工作正常，我可以登录到 CloudHub 并查看填充在我的 DLQ 上的消息 - 但是当端点恢复时，它似乎无法将消息从该队列移回流中。您在 CloudHub 中似乎所能做的就是清除您的队列。同样，这是否可能仅使用 VM 队列和 CloudHub（即没有其他排队工具）？
4

1 回答 1

1

虚拟机队列非常基础，无论您是否在 CloudHub 中使用它们。

  1. VM 队列没有延迟重新交付的能力（如指数回退）。如果您需要此类功能，请使用 JMS 队列。
  2. 您需要创建一个用于处理 DLQ 的流，例如通过请求者模块定期使用队列并将消息重新注入主队列的流。同样，使用 JMS，您将拥有更好的控制力。

除了 JMS，您可以考虑托管队列，如 CloudAMQP、Iron.io 或 AWS SQS。您将失去对入站端点的事务支持，但会更好地控制（重新）交付行为。

于 2015-03-10T16:05:26.490 回答