徵兆:
訊息產生延遲或代理程式拒絕產生的訊息。
訊息需要超長的時間才能到達用戶。
代理程式 (或特定目標) 中的訊息數目或訊息容量隨著時間穩定增加。
若要查看是否累積訊息,請檢查代理程式中的訊息數目或訊息容量如何不斷變化,並與配置的限制進行比較。請先檢查配置的限制:
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 標頭下列出的訊息數目,是否與目標中的訊息數目相同。此標頭下的訊息已傳送到用戶,但是尚未經過確認。如果這個數目與訊息總數相同,表示代理程式已經送出所有訊息,正在等待確認。
若要解決此問題:請應用程式開發者協助除錯此問題。