儲存訊息

徵兆：

• 訊息產生延遲或代理程式拒絕產生的訊息。

• 訊息需要超長的時間才能到達用戶。

• 代理程式 (或特定目標) 中的訊息數目或訊息容量隨著時間穩定增加。

若要查看是否累積訊息，請檢查代理程式中的訊息數目或訊息容量如何不斷變化，並與配置的限制進行比較。請先檢查配置的限制：

imqcmd query bkr

---

備註 –

imqcmd metrics bkr 子指令不會顯示此資訊。

---

接著檢查每個目標中的訊息累積：

imqcmd list dst

若要查看訊息是否超過所配置的目標或整個代理程式的限制，請檢查代理程式記錄中是否有以下項目：

[B2011]: Storing of JMS message from … failed.

此項目後面還有其他項目，說明已超過限制。

可能原因：

• 主題目標上有非使用中的長期訂閱

• 佇列中可使用訊息的用戶太少

• 訊息用戶處理速度過慢，無法跟上訊息產生器的速度

• 用戶端確認處理會降低訊息使用速度

• 代理程式無法跟上產生訊息的速度

• 用戶端程式碼缺點；用戶不確認訊息

可能原因：主題目標上有非使用中的長期訂閱。

如果長期訂閱為非使用中，則訊息會儲存在目標中，直到對應的用戶變為使用中狀態並能使用這些訊息為止。

若要確認此問題的原因：檢查每個主題目標上的長期訂閱狀態：

imqcmd list dur -d destName

若要解決此問題：

• 清除違例長期訂閱的所有訊息 (請參閱管理長期訂閱)。

• 指定用於主題的訊息限制和限制運作方式屬性 (請參閱表 15–1)。例如，您可以指定 REMOVE_OLDEST 和 REMOVE_LOW_PRIORITY 限制運作方式，以刪除記憶體中累積的訊息。

• 從對應的目標清除所有訊息 (請參閱清除實體目標)。

• 重新寫入訊息產生用戶端以設定每個訊息的存在時間值，來限制訊息可保留在記憶體中的時間。您可以置換共用一條連線之所有產生器的任何此類設定值，方法為設定 imqOverrideJMSExpiration 和 imqJMSExpiration 連線工廠屬性 (請參閱 訊息標頭置換)。

可能原因：佇列中可使用訊息的用戶太少。

如果可接收所傳送訊息的使用中用戶太少，則訊息累積時可能會積存在佇列目標中。此情況會因以下任何一種原因而發生：

• 目標中存在的使用中用戶太少。

• 訊息使用用戶端建立連線失敗。

• 沒有使用中用戶使用符合佇列中訊息的選擇器。

若要確認此問題的原因：請檢查目標上使用中用戶的數目，以便幫助您判斷用戶為何無法使用：

imqcmd metrics dst - n destName -t q -m con

若要解決此問題：根據無法使用用戶的原因：

• 啟動其他訊息使用用戶端，為佇列建立更多使用中用戶。

• 調整 imq.consumerFlowLimit 代理程式特性，使得佇列傳送訊息至多個用戶的效能最佳化 (請參閱多重用戶佇列效能)。

• 指定用於佇列的訊息限制和限制運作方式屬性 (請參閱表 15–1)。例如，您可以指定 REMOVE_OLDEST 和 REMOVE_LOW_PRIOROTY 限制運作方式，以刪除記憶體中累積的訊息。

• 從對應的目標清除所有訊息 (請參閱清除實體目標)。

• 重新寫入訊息產生用戶端以設定各個訊息的存在時間值，來限制訊息可保留在記憶體中的時間。您可以置換用於共用連線之所有產生器的任何此類設定值，方法為設定 imqOverrideJMSExpiration 和 imqJMSExpiration 連線工廠屬性 (請參閱 訊息標頭置換)。

可能原因：訊息用戶處理速度過慢，無法跟上訊息產生器的速度。

在此狀況下，主題訂閱者或佇列接收者使用訊息的速度，會比產生器傳送訊息的速度慢。因為此不平衡現象，所以一個或多個目標中會出現訊息積存。

若要確認此問題的原因：檢查傳入和傳出代理程式之訊息流量的速率：

imqcmd metrics bkr -m rts

然後檢查每個個別目標的流量速率：

imqcmd metrics bkr -t destType -n destName - m rts

若要解決此問題：

• 最佳化訊息使用用戶端程式碼。

• 增加用於佇列目標的使用中用戶數目 (請參閱多重用戶佇列效能)。

可能原因：用戶端確認處理會降低訊息使用速度。

有兩個因素會影響用戶端確認處理：

• 處理用戶端確認時會大量使用代理程式資源。因此，使用這些確認模式可能會降低訊息使用的速度，因為訊息使用用戶端會阻斷，直到代理程式確定用戶端確認為止。

• JMS 有效負載訊息和 Message Queue 控制訊息 (例如用戶端確認) 共用同一個連線。因此，JMS 有效負載訊息可能會阻擋控制訊息，因而降低訊息使用的速度。

若要確認此問題的原因：

• 檢查與封包流量相關的訊息流量。如果每秒的封包數目與訊息數目不成比例，則用戶端確認可能有問題。

• 檢查用戶端是否接收到下列異常：

  JMSException [C4000]: Packet acknowledge failed

若要解決此問題：

• 修改用戶端所使用的確認模式：例如，改為使用 DUPS_OK_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE。

• 如果使用 CLIENT_ACKNOWLEDGE 或已處理的階段作業，請將更大數目的訊息集合成單一確認的群組。

• 調整用戶和連線流量控制參數 (請參閱用戶端執行階段訊息流量調校 )。

可能原因：代理程式無法跟上產生訊息的速度。

在此狀況下，訊息傳入代理程式的速度，會比代理程式路由和派送訊息到用戶的速度快。代理程式運作遲緩可以是因為以下任何或所有限制造成：

• CPU

• 網路通訊端讀取/寫入作業

• 磁碟讀取/寫入作業

• 記憶體分頁

• 永久性存放區

• JVM 記憶體限制

若要確認此問題的原因：檢查是否有其他可能造成此問題的原因。

若要解決此問題：

• 升級您電腦或資料存放區的速度。

• 使用代理程式叢集，分發一些代理程式實例上的負載。

可能原因：用戶端程式碼缺點；用戶不確認訊息。

在所有要接收所傳送之訊息的用戶確認訊息之前，這些訊息會被保留在目標中。如果用戶端不確認使用的訊息，那麼訊息會累積在目標中且不被刪除。

舉例來說，用戶端程式碼可能會有以下缺點：

• 使用 CLIENT_ACKNOWLEDGE 確認模式或已處理的階段作業的用戶，可能不會定期呼叫Session.acknowledge或Session.commit。

• 使用 AUTO_ACKNOWLEDGE 確認模式的用戶可能因某些原因而當機。

若要確認此問題的原因：首先，檢查本節中列出的所有其他可能原因。然後，使用下列指令，列出目標：

imqcmd list dst

請注意 UnAcked 標頭下列出的訊息數目，是否與目標中的訊息數目相同。此標頭下的訊息已傳送到用戶，但是尚未經過確認。如果這個數目與訊息總數相同，表示代理程式已經送出所有訊息，正在等待確認。

若要解決此問題：請應用程式開發者協助除錯此問題。