Mule ESB CE 3.5.0 TCP 重连策略答案

【问题标题】：Mule ESB CE 3.5.0 TCP Reconnection StrategiesMule ESB CE 3.5.0 TCP 重连策略
【发布时间】：2015-02-18 22:07:55
【问题描述】：

我正在使用 Mule ESB CE 3.5.0 并看到我认为是 TCP 连接上的资源泄漏。我正在连接 VisualVM 并检查内存。我看到它随着时间的推移而增加而不会减少。

我的场景是我有消息被发送到 Mule，Mule 做它的事情，然后分派到远程 TCP 端点（通常在同一个盒子上）。我所做的并不是启动从 Mule 的 TCP 出站端点接收消息的程序。所以没有任何东西在监听 Mule 发送的消息。

我将我的 TCP 连接器配置如下：

<tcp:connector name="TcpConnector" keepAlive="true" keepSendSocketOpen="true" sendTcpNoDelay="true" reuseAddress="true">
    <reconnect-forever frequency="2000" />
    <tcp:xml-protocol />
</tcp:connector>

<tcp:endpoint name="TcpEndpoint1" responseTimeout="3000" connector-ref="TcpConnector" host="${myHost}" port="${myPort}" exchange-pattern="one-way" />

我的问题是：

当流无法发送到 TCP 出站端点时，消息会发生什么情况？消息是否保存在内存中的某个地方，一旦 TCP 连接器与远程端点建立连接，是否所有累积的消息都会突发并被分派？
当重新连接策略阻塞时，我假设它是一个试图建立连接的调度程序线程。如果我们有更多消息要分派，那么是否有更多的分派器线程与尝试重新连接有关？如果它是非阻塞的会发生什么？

谢谢！

编辑：

如果我也理解the threading documentation correctly，这是否意味着如果我将默认线程配置文件设置为 poolExhaustedAction="RUN"，并且所有调度程序线程阻塞等待连接，最终是流线程，然后是接收器线程将阻止尝试建立连接。当远程应用再次开始监听时，所有来自被阻塞线程的积压消息都会爆发。

因此，如果流接收到瞬态数据，则应将其配置为具有非阻塞重新连接，并且由于丢弃消息是可以接受的（在我的用例中），那么我们可以处理将抛出的异常.

【问题讨论】：

标签： sockets tcp mule esb

【解决方案1】：

我会指给你documentation：

非阻塞重连

默认情况下，重连策略会阻塞Mule应用消息处理，直到它能够连接/重新连接。当你启用非阻塞重连，应用程序不需要等待所有端点重新连接，然后再重新启动。此外，如果连接丢失，则在线程上重新连接与应用程序线程分开。请注意，此类行为可能或可能不理想，具体取决于您的应用程序需求。

关于阻塞重新连接策略，您将得到的是调度程序将被阻塞，等待可用连接。从技术上讲，这些消息并未保存在任何地方，它们的流动只是停止了。

关于第二个问题，它在运输和运输之间变化。在这种非常特殊的情况下，鉴于 tcp 是每个请求传输的连接，不同的调度程序将尝试从connections 的池中get 不同的套接字。

在非阻塞策略的情况下，您将获得异常。您可能可以轻松地对其进行测试。

【讨论】：