Mule ESB CE 3.5.0 TCP重新連接策略

我正在使用Mule ESB CE 3.5.0，並且看到我認爲是TCP連接上的資源泄漏。我連接VisualVM並檢查內存。我發現它隨着時間的推移而不斷減少。Mule ESB CE 3.5.0 TCP重新連接策略

我的場景是我有消息被髮送到Mule，Mule做它的事情，然後調度到遠程TCP端點（通常在同一個盒子上）。我所做的不是啓動該程序，該程序會收到來自Mule的TCP出站端點的消息。所以沒有人聽取穆勒的調度信息。

配置我的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」，所有的調度程序線程阻塞等待連接，最終流線，然後接收者線程在嘗試建立連接時會阻塞。當遠程應用程序再次開始監聽時，來自被阻止的線程的所有積壓的消息將突然通過。

所以如果流接收到瞬態數據，它應該配置爲無阻塞重新連接，並且由於丟棄消息是可以接受的（在我的使用情況下），那麼我們可以處理異常拋出。

來源

2014-12-19 Randy

我想指出你的documentation：

非阻塞重聯

默認情況下，重新連接戰略將阻止騾子應用消息處理直到它能夠連接/重新連接。當您啓用無阻塞重新連接時，應用程序不需要等待所有端點在重新啓動之前重新連接。此外，如果連接丟失，則重新連接發生在與應用程序線程分離的線程中。請注意，根據您的應用程序需求，這種行爲可能並不合適，或者可能不合需要。

關於阻塞重新連接策略你將得到的是調度器將被阻塞，爲可用連接維持。這些消息在技術上並沒有保存在任何地方，他們的流量就停止了。

關於第二個問題，它在運輸和運輸之間變化。在這個非常特殊的情況下，考慮到tcp是每個請求傳輸的連接，不同的調度器將嘗試從connections的池中嘗試get不同的套接字。

在非阻塞策略的情況下，你會得到一個例外。你可以很容易地測試它。

來源

2014-12-19 23:11:03

Mule ESB CE 3.5.0 TCP重新連接策略

回答

相關問題