重连接策略与哪些骡子传输一起工作？

Question

重连接策略文档只使用JMS示例，但是FTP传输文档确实声明了重新连接策略的使用，但没有任何细节或示例。

此外，如果您查看这个回答 @David提到，重新连接只适用于某些传输(连接传输)。

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

我的第二个问题是骡子文献对下面的副词的一个简单的解释:)

对于配置有同步入站和出站端点但没有重新连接策略的FTP传输，如果出站连接中断，所有入站消息都会失败，因为入站端点继续接收消息。相反，在重新连接策略到位后，系统会丢失失败的第一条消息(因为FTP不是事务性的)，但是一旦重新连接策略生效，入站端点就不会接受进一步的消息(因此不会丢失)，直到重新建立连接为止。

当他们说下一行时，是指入站或出站的重新连接吗？同样地，他们是否假设在入站或出站时失去了连接？

相反，重新连接策略已经到位。

我的第三个问题来自于这个冗长的讨论，在讨论的各个方面，如下所示

重连接与出站重试无关，当尝试发送出站失败时，它不会起作用，而是只对需要处理意外断开连接的连接传输(如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服务器完全不同。