我知道 DefaultMessageListenerContainer 設計的輪詢。并且設定輪詢間隔的receiveTimeout默認為1秒。
我理解的方式是 DMLC 將發出一個 get，并在超時并發出另一個 get 之前等待“receiveTimeout”定義的間隔（1 秒）。
根據我的閱讀，我們可以將此receiveTimout值設定為更大的值，并且對從 MQ 獲取的訊息沒有影響，因為活動的“get”將坐在偵聽器上，直到訊息到達......并且一旦/如果超時間隔到期，它只會提交另一個在佇列中保持活動狀態的獲取，直到訊息到達。
所以我的問題是，較小的 receiveTimout 間隔有什么好處？如果我們總是要在訊息到達時對其進行處理，那我們到底為什么要每秒輪詢一次佇列呢？
我們正在運行許多大型應用程式，而輪詢只是通過屋頂運行 CPU 使用率/賬單，我找不到這樣做的理由。
uj5u.com熱心網友回復：
是的 - 1 秒的接收超時對于大量佇列來說可能是 CPU 密集型的。
DefaultMessageListenerContainer 的總體思路是稍等片刻（1 秒似乎是一個非常短的等待期），然后，如果您沒有收到訊息，它實際上會破壞所有內容并進行完全重新連接。這是一種窮人的錯誤處理。“如果我還沒有收到經紀人的訊息，請假設有什么東西壞了，放下所有東西并重新連接”。如果重新連接不是那么昂貴，那么這可能不是一個壞策略。或者，如果您只有一個佇列。或者，您可能希望每秒收到 10 條訊息，并且如果一秒鐘過去了，您確實希望重新連接。如果您有合理數量的目的地，那么重新連接的流量可能會變得非常糟糕。
對于 IBM MQ，JMS 連接/會話上的故障被可靠地拾取。您沒有“由于某種原因它只是坐在那里沒有收到任何訊息”的場景。因此，將超時設定為 10 分鐘（無論如何）就可以了。
請注意，如果您在 JEE 應用程式服務器中運行，并且您的 JMS 連接由 JCA 管理，那么該層負責檢測不良連接，您不必在應用程式層擔心它。
使用 Camel 和 SpringBoot GitHub可能會有用。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/495520.html
上一篇：Java：特定Object作為Iterable中的泛型型別
下一篇：如何用樹以角度下載檔案？