重新连接策略使用哪种mule运输

该文档仅使用JMS示例，但并未说明重新连接策略的使用，但没有任何细节或示例

此外，如果您看这个@David提到，重新连接将只适用于某些传输（连接的传输）

因此，我的第一个问题——我们是否可以有一些正式的机制/指南/规则来确定重新连接机制将使用哪些传输，以及它不适用于哪些传输。。这可能是可以破译的，但一个具体的东西将是伟大的

我的第二个问题是对以下段落的简单解释：）

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

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

相比之下，在重新连接策略到位的情况下

我的第三个问题是在下面的讨论中从不同的角度提出的

重新连接与出站重试无关，它不会出现 当尝试发送出站失败但仅针对已连接的 需要处理意外断开连接的传输（如JMS）

---

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

大部分冗长的讨论都来自重新连接和重试之间的混淆：前者在连接器/端点级别起作用，确保端点继续工作（轮询器轮询、侦听器侦听、分派器分派），后者在消息级别执行操作，确保端点中不会丢失任何消息

---

在FTP的情况下，Mule不维护长时间运行的出站连接，但它使用noop对其进行验证（请参阅：对于出站端点和对于入站端点）

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

当Mule回收连接器时，它会关闭并重新启动其所有相关端点（更严格地说，是消息接收器和发送器）

由于Mule验证FTP端点（见上文），因此如果连接器的任何入站或出站端点无法执行测试FTP noop，连接器将不会达到

start

状态

---

基于此，您的问题中关于FTP的讨论应该会更清楚。如果最初导致Mule回收FTP连接器的远程FTP服务器问题持续存在，则此连接器管理的所有入站/出站端点都不会达到启动状态，即使这些端点处理的是完全不同的FTP服务器。

谢谢同意，也可以用你对这三个主题的想法更新你的答案mentioned@Sudarshan在FTP案例中添加了更多的措辞。太好了！！，Mule可以从您那里获得一些文档帮助：）