sockets - Mule ESB CE 3.5.0 TCP 重新连接策略

Question

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

我的场景是我有消息被发送到 Mule，Mule 做它的事情，然后分派(dispatch)到远程 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" />

我的问题是:

1. 当流无法发送到 TCP 出站端点时，消息会发生什么情况？消息是否保存在内存中的某个位置，一旦 TCP 连接器与远程端点建立连接，是否所有累积的消息都会爆发并被分派(dispatch)？

2. 当重新连接策略处于阻塞状态时，我假设它是一个尝试建立连接的调度程序线程。如果我们有更多消息要分派(dispatch)，那么是否有更多分派(dispatch)器线程与尝试重新连接相关联？如果它是非阻塞的会怎样？

谢谢!

编辑:

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

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

Answer 1

我会向您指出 documentation :

Non-Blocking Reconnection

By default, a reconnection strategy will block Mule application message processing until it is able to connect/reconnect. When you enable non-blocking reconnection, the application does not need to wait for all endpoints to re-connect before it restarts. Furthermore, if a connection is lost, the reconnection takes place on a thread separate from the application thread. Note that such behavior may or may not be desirable, depending on your application needs.

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

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

在非阻塞策略的情况下，你会得到一个异常(exception)。您或许可以轻松地对其进行测试。