mule - 重新连接策略适用于哪些 mule 传输

Question

reconnection strategies文档仅使用 JMS 示例，但是 FTP transport documentation确实说明了重新连接策略的使用，但没有任何细节或示例。

进一步，如果你看这个answer @David 提到重新连接仅适用于某些传输(已连接的传输)。

所以我的第一个问题——我们能否有一些正式的机制/指南/规则来确定重新连接机制将适用于哪些传输，哪些不适用……这可能是可以破译的，但是一些具体的东西会很棒..

我的第二个问题是对来自 mule documentation 的以下段落的简单解释。 :)

For an FTP transport configured with synchronous inbound and outbound endpoints, but no reconnection strategy, all inbound messages fail if the outbound connection goes down, because the inbound endpoint continues to receive messages. By contrast, with a reconnection strategy in place, the system loses the first message that fails (since FTP is not transactional) but once the reconnection strategy goes into effect, no further messages are accepted by the inbound endpoint (and thus, none are lost) until the connection is re-established.

当他们说下面这行时，是指在入站还是出站重新连接？同样，他们是否假设在入站或出站时失去连接

By contrast, with a reconnection strategy in place

我的第三个问题来自这个 lengthy discussion在讨论的不同点，如下所示

Reconnection has nothing to do with outbound retries, it doesn't come into play when attempts to send outbound fail but only for connected transports (like JMS) that needs to handle unexpected disconnections.

似乎我们被告知重新连接策略不适用于出站端点，请有人澄清我是否理解正确。

Answer 1

大部分冗长的讨论来自重连和重试之间的混淆:前者作用于连接器/端点级别并确保端点保持工作(轮询器轮询、监听器监听、调度器调度)，后者作用于消息级别并确保端点中没有消息丢失。

---

在 FTP 的情况下，Mule 不维护长时间运行的出站连接，但它使用 noop 验证它们(请参阅:https://github.com/mulesoft/mule/blob/mule-3.x/transports/ftp/src/main/java/org/mule/transport/ftp/FtpMessageDispatcher.java#L109 用于出站端点和 https://github.com/mulesoft/mule/blob/mule-3.x/transports/ftp/src/main/java/org/mule/transport/ftp/FtpMessageReceiver.java#L229 用于入站端点)。

因此，如果在上传文件时检测到远程服务器问题，并且在 FTP 连接器上配置了重新连接策略，Mule 将回收连接器。

当 Mule 回收连接器时，它会关闭并重新启动所有相关的端点(更专业地说:消息接收器和调度器)。

因为 Mule 验证 FTP 端点(见上文)，如果连接器的任何入站或出站端点无法执行测试 FTP noop，连接器将不会达到 started 状态。

基于此，你问题中关于FTP的讨论应该会变得更加清晰。如果最初使 Mule 回收 FTP 连接器的远程 FTP 服务器问题仍然存在，则此连接器管理的输入/输出端点都不会达到启动状态，即使这些端点处理完全不同的 FTP 服务器也是如此。