重新连接策略适用于哪些骡子运输

Question

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

如果您进一步查看answer@David 提到重新连接仅适用于某些传输（连接传输）。

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

我的第二个问题是对mule documentation 中以下段落的更简单解释：)

对于配置了同步入站和出站的 FTP 传输 端点，但没有重新连接策略，所有入站消息都会失败，如果 出站连接断开，因为入站端点 继续接收消息。相比之下，重新连接 策略到位，系统丢失第一条失败的消息 （因为 FTP 不是事务性的）但是一旦重新连接策略 生效，入站不再接受更多消息 端点（因此，没有丢失），直到连接 重新建立。

当他们说下面这行时，他们的意思是在入站或出站重新连接吗？同样，他们假设入站或出站连接丢失

相比之下，重新连接策略到位

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

重新连接与出站重试无关，它不会来 当尝试发送出站失败但仅适用于已连接时发挥作用 需要处理意外断开连接的传输（如 JMS）。

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

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 服务器也是如此。