reconnection strategies文档仅使用JMS示例，但FTP transport documentation确实说明了重新连接策略的使用，但没有任何细节或示例。
此外，如果您查看此answer @David，请注意重新连接仅适用于某些传输（连接传输）。
所以我的第一个问题 - 我们是否可以有一些正式的机制/指导方针/规则来确定重新连接机制将使用哪些传输以及哪些传输不适用..这可能是破译的，但具体的东西会很棒..
我的第二个问题是对mule documentation下面的paragrapgh的一个更简单的解释：）
对于使用同步入站和出站配置的FTP传输 端点，但没有重新连接策略，所有入站消息都失败了 出站连接断开，因为入站端点 继续收到消息。相比之下，重新连接 策略到位后，系统会丢失第一个失败的消息 （因为FTP不是事务性的）但是一旦重新连接策略 生效后，入站不再接收任何消息 在连接之前，端点（因此，没有丢失） 重新建立。
当他们说下面的行时，他们是指在入站或出站重新连接？同样，他们假设在入境或出境时失去联系
相比之下，采用重新连接策略
我的第三个问题来自于此lengthy discussion，讨论的各个方面如下
重新连接与出站重试无关，但它没有出现 尝试发送出站失败但仅为已连接时发挥作用 需要处理意外断开的传输（如JMS）。
似乎我们被告知重新连接策略不适用于出站端点，有人可以澄清我是否已正确理解这一点。
答案 0 :(得分：2)
大多数冗长的讨论来自重新连接和重试之间的混淆：前者在连接器/端点级别执行并确保端点继续工作（轮询器轮询，侦听器侦听，调度程序调度），后者在消息级别执行并确保在端点中没有消息丢失。
对于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服务器。