重新连接策略适用于哪个m子传输 [英] Which mule transports does the re-connection strategy work with

问题描述

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

The reconnection strategies documentation only uses JMS examples, however the FTP transport documentation does state the use of re-connection strategies, without any details or examples though.

此外，如果您查看此答案，@ David提到了连接仅适用于某些传输(连接的传输).

Further if you look at this answer @David mentions that re-connection will work with only some transports (connected transport).

所以我的第一个问题-我们是否可以有一些正式的机制/准则/规则来确定重新连接机制将与哪些传输一起使用，哪些不适用.会很棒..

So my first question -- Can we have some formal mechanism/guidelines/rules of determining which transports the re-connection mechanism will work with and for which it does not apply .. This can probably be deciphered, but a something concrete would be great ..

我的第二个问题是 ule子文档:)

对于配置了同步入站和出站的FTP传输 端点，但没有重新连接策略，如果 出站连接断开，因为入站端点 继续接收消息.相比之下，重新连接 策略到位，系统将丢失第一个失败的消息 (因为FTP不是事务性的)，但是一旦重新连接策略 生效，入站不接受进一步的消息 终结点(因此不会丢失)，直到连接成功 重新建立.

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.

当他们说下一行时，是指在入站还是出站重新连接?同样，他们假设入站或出站失去连接

When they say the below line, do they mean re connection at inbound or outbound ? and similarly are they assuming loss of connection at inbound or outbound

相比之下，采用适当的重新连接策略

By contrast, with a reconnection strategy in place

我的第三个问题来自这个冗长的讨论下面

My third question is from this lengthy discussion at various points in the discussion like the below

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

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.

似乎我们被告知重新连接策略不适用于出站终结点，请问有人可以澄清一下我是否正确理解这一点.

It seems like we are being told that reconnection strategy does not apply to outbound endpoints, can someone clarify if I have understood this correctly please.

推荐答案

大部分冗长的讨论来自于重新连接和重试之间的混淆:前者在连接器/端点级别起作用，并确保端点保持工作状态(轮询轮询，监听器)侦听，调度程序调度)，后者在消息级别起作用，并确保在端点中不会丢失任何消息.

Most of the lengthy discussion comes from the confusion between reconnection and retry: the former acts at connector/endpoint level and ensures that endpoints keep working (poller polls, listeners listen, dispatchers dispatch), the latter acts at message level and ensures that no message gets lost in an endpoint.

对于FTP，Mule不会维护长期运行的出站连接，但会通过noop验证它们(请参阅:

In the case of FTP, Mule does not maintain long running outbound connections, but it validates them with a noop (see: 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 for inbound endpoints).

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

So, if a remote server issue is detected when uploading a file, and if a reconnection strategy is configured on the FTP connector, Mule will recycle the connector.

当Mule回收连接器时，它将关闭并重新启动其所有相关端点(从技术上来说:消息接收器和调度程序).

When Mule recycles a connector, it shuts down and restarts all its related endpoints (more technically: message receivers and dispatchers).

由于Mule验证了FTP端点(请参阅上文)，如果连接器的任何入站或出站端点无法执行测试FTP noop，则连接器将不会达到started状态.

Because Mule validates FTP endpoints (see above), the connector will not reach the started state if any of its inbound or outbound endpoints can't perform the test FTP noop.

基于此，您的问题中关于FTP的讨论应该变得更加清晰.如果最初使Mule回收FTP连接器的远程FTP服务器问题仍然存在，则即使该端点处理完全不同的FTP服务器，该连接器管理的所有入/出端点也不会达到启动状态.

Based on this, the discussion about FTP in your question should become clearer. If the remote FTP server issue that initially made Mule recycle the FTP connector persists, none of the in/outbound endpoints managed by this connector will reach the started state, even if these endpoints deal with completely different FTP servers.

这篇关于重新连接策略适用于哪个m子传输的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！