我們有一個類似于這個老問題的問題。然而，我們的設(shè)置有點不同。例如，心跳應(yīng)該已經(jīng)存在，因為我們有來自 ActiveMQ 的默認 InactivityMonitor。我們有一個使用嵌入式經(jīng)紀人的客戶。嵌入式代理有一個網(wǎng)絡(luò)連接器，可以連接到作為機器上的獨立服務(wù)運行的遠程代理。通過這種方式，我們可以解耦客戶端和服務(wù)器之間的通信。嵌入式代理充當客戶端的本地隊列?？蛻舳讼蚯度胧酱戆l(fā)送消息。這些消息要么通過網(wǎng)絡(luò)連接器流向遠程代理，要么（當連接暫時不可用時）留在嵌入式代理中，直到重新建立連接。嵌入式代理和遠程代理都是 Apache ActiveMQ 的實例。JMS 實現(xiàn)基于 Spring JMS。在實踐中，我們有時會看到奇怪的行為（通常在很長一段時間后沒有任何問題）：網(wǎng)絡(luò)連接器列在遠程代理管理控制臺的連接選項卡中。但是，并非所有消息都在遠程代理處傳遞。通常字節(jié)消息被卡在嵌入式代理中，而文本消息被傳遞到遠程代理上的隊列。網(wǎng)絡(luò)連接器列在遠程代理管理控制臺的連接選項卡中。但是，沒有消息正在遠程代理處傳遞。在遠程代理上啟用了不活動監(jiān)視器。嵌入式代理是使用下面顯示的代碼創(chuàng)建的（為簡潔起見省略了 SSL 代碼）。我們不知道可能導(dǎo)致問題的原因，更重要的是，不知道為什么設(shè)置不會自動恢復(fù)。我們希望此設(shè)置能夠自動檢測連接不可用并設(shè)置新連接。然而，這似乎并沒有發(fā)生。有沒有人知道我們可以從哪里開始尋找，或者更好的是，知道問題可能出在哪里？