重新连接策略适用于哪些 mule 传输
Which mule transports does the re-connection strategy work with
reconnection strategies documentation only uses JMS examples, however the FTP transport documentation确实说明了重新连接策略的使用，但没有任何细节或示例。
此外，如果您查看此 answer @David 提到重新连接将仅适用于某些传输（已连接的传输）。
所以我的第一个问题 -- 我们能否有一些正式的 mechanism/guidelines/rules 来确定重新连接机制将适用于哪些传输，哪些不适用......这可能是可以破译的，但是具体的东西会很棒..
我的第二个问题是对 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.
好像我们被告知重新连接策略不适用于出站端点，请有人澄清我是否理解正确。
大部分冗长的讨论来自重连和重试之间的混淆：前者在 connector/endpoint 级别起作用并确保端点保持工作（轮询轮询、侦听器侦听、调度程序调度），后者在 connector/endpoint 级别起作用消息级别并确保没有消息在端点中丢失。
在 FTP 的情况下，Mule 不维护长 运行 出站连接，但它使用 noop 验证它们（请参阅：https://github.com/mulesoft/mule/blob/mule-3.x/transports/ftp/src/main/java/org/mule/transport/ftp/FtpMessageDispatcher.java#L109 for outbound endpoints and 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 个端点（见上文），如果它的任何入站或出站端点无法执行测试，连接器将不会达到 started 状态 FTP没有。
基于此，您问题中关于 FTP 的讨论应该会变得更加清晰。如果最初使 Mule 回收 FTP 连接器的远程 FTP 服务器问题仍然存在，则此连接器管理的 in/outbound 端点中的 none 将达到启动状态，即使这些端点处理完全不同的 FTP 服务器。
reconnection strategies documentation only uses JMS examples, however the FTP transport documentation确实说明了重新连接策略的使用，但没有任何细节或示例。
此外，如果您查看此 answer @David 提到重新连接将仅适用于某些传输（已连接的传输）。
所以我的第一个问题 -- 我们能否有一些正式的 mechanism/guidelines/rules 来确定重新连接机制将适用于哪些传输，哪些不适用......这可能是可以破译的，但是具体的东西会很棒..
我的第二个问题是对 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.
好像我们被告知重新连接策略不适用于出站端点，请有人澄清我是否理解正确。
大部分冗长的讨论来自重连和重试之间的混淆：前者在 connector/endpoint 级别起作用并确保端点保持工作（轮询轮询、侦听器侦听、调度程序调度），后者在 connector/endpoint 级别起作用消息级别并确保没有消息在端点中丢失。
在 FTP 的情况下，Mule 不维护长 运行 出站连接，但它使用 noop 验证它们（请参阅：https://github.com/mulesoft/mule/blob/mule-3.x/transports/ftp/src/main/java/org/mule/transport/ftp/FtpMessageDispatcher.java#L109 for outbound endpoints and 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 个端点（见上文），如果它的任何入站或出站端点无法执行测试，连接器将不会达到 started 状态 FTP没有。
基于此，您问题中关于 FTP 的讨论应该会变得更加清晰。如果最初使 Mule 回收 FTP 连接器的远程 FTP 服务器问题仍然存在，则此连接器管理的 in/outbound 端点中的 none 将达到启动状态，即使这些端点处理完全不同的 FTP 服务器。