|
| |
| Sun Java System Message Queue 3 2005Q4 管理指南 | |
第 12 章
排解疑難問題本章說明如何瞭解及解決下列問題：
發生問題時，檢查所安裝的 Message Queue 軟體的版本編號，通常很有幫助。版本編號可讓您確定所用文件的編號是否與軟體版本相符。此外，向 Sun 報告問題時，也需要版本編號。若要檢查版本編號，請發出以下指令：
imqcmd -v
用戶端無法建立連線此問題有下列徵兆：
本節提供下列幾種可能原因：
用戶端應用程式未關閉連線，導致連線數目超過資源限制
確認此問題的原因
列出所有代理程式的連線：
imqcmd list cxn
輸出會列出所有連線和建立每個連線的主機，顯示特定用戶端異常多的開啟連線。
若要解決此問題
重新寫入違例用戶端，以關閉不使用的連線。
未執行代理程式或網路連結發生問題
確認此問題的原因
若要解決此問題
連線服務不在使用中或已暫停
確認此問題的原因
檢查所有連線服務的狀態：
imqcmd list svc
如果連線服務狀態顯示如下 unknown (未知) 或 paused (暫停中)，用戶端無法使用服務建立連線。
若要解決此問題
若要正確配置 SSL 服務，請參閱使用 SSL 型服務。
- 如果連線服務狀態顯示為 paused (暫停中)，會繼續服務 (請參閱暫停和繼續連線服務)。
可用於所需連線數目的可用執行緒太少
確認此問題的原因
檢查代理程式記錄中是否有以下項目：
警告 [B3004]：沒有可用於服務上處理新連線的執行緒...關閉新的連線。
再使用下列其中一種格式，檢查連線服務上的連線數目和目前使用中的執行緒數目：
imqcmd query svc -n serviceName
imqcmd metrics svc -n serviceName -m cxn
每個連線均需要兩個執行緒：一個用於內送訊息，另一個用於外寄訊息 (請參閱執行緒池管理)。
若要解決此問題
- 如果您使用專用執行緒池模型
(imq.serviceName. threadpool_model=dedicated)，則最大的連線數目為執行緒池中最大執行緒數目的一半。因此，若要增加連線數目，請增加執行緒池的容量 (imq.serviceName.max_threads) 或切換為共用執行緒池模型。- 如果您使用共用執行緒池模型 (imq.serviceName. threadpool_model=shared)，則最大的連線數目為以下兩種特性產品的一半：連線監視限制 (imq.serviceName.connectionMonitor_limit) 和最大執行緒數目 (imq.serviceName.max_threads)。因此，若要增加連線數目，請增加執行緒池的大小或增加連線監視限制。
- 可支援的連線數目 (或連線上的流量) 最終會達到輸入/輸出限制。在此情況下，請使用多重代理程式叢集，以分散叢集中代理程式實例上的連線。
Solaris 或 Linux 作業系統上要求用於連線數目的檔案描述元太少
如需有關此問題的更多資訊，請參閱設定檔案描述元限制。
確認此問題的原因
檢查代理程式記錄中是否有以下相似項目：開啟的檔案太多。
若要解決此問題
增加檔案描述元限制，如 ulimit 線上援助頁所述。
TCP 儲存區會限制可同時新建連線請求的數目
TCP 儲存區會在連接埠對映器拒絕其他請求前，限制同時儲存在系統儲存區內的連線請求數目 (imq.portmapper.backlog)。(在 Windows 作業系統上有程序內定的儲存區限制：Windows Desktop 的數目為 5，Windows Server 的數目為 200。)
因為不會經常出現同時有大量的連線請求，所以因儲存區限制的請求拒絕通常為短暫現象。
確認此問題的原因
檢查代理程式記錄。首先，檢查代理程式在拒絕其他連線的同時是否有接受某些連線。接著，檢查拒絕連線的說明訊息。如果找到這類訊息，可能不是 TCP 儲存區的問題，因為代理程式不記錄 TCP 儲存區造成的拒絕連線。
如果有記錄連線成功但沒有記錄拒絕連線，則可能是 TCP 儲存區的問題。
若要解決此問題
可以用以下方法來解決 TCP 儲存區限制：
作業系統會限制運作中連線的數目
Windows 作業系統授權會限制支援的同時運作遠端連線的數目。
確認此問題的原因
檢查可用於連線的執行緒數目 (使用 imqcmd query svc)，並檢查 Windows 授權合約的條款。如果您是從本地用戶端建立連線，而不是從遠端用戶端，作業系統限制可能是造成此問題的原因。
若要解決此問題
使用者的認證或授權失敗
驗證可能會因為錯誤密碼而失敗，因為沒有使用者進入使用者儲存庫的項目，或因為使用者沒有存取連線服務的權限。
確認此問題的原因
檢查代理程式記錄中是否有禁用錯誤訊息的項目。這表示有驗證錯誤，但不表示為問題發生的原因。
若要解決此問題
- 如果使用者儲存庫中沒有用於使用者的項目，請將使用者新增到使用者儲存庫 (請參閱寫入和管理使用者儲存庫)。
- 如果使用的密碼錯誤，請提供正確的密碼。
- 如果存取控制特性未正確設定，請編輯存取控制特性檔案，以取得連線服務權限 (請參閱連線服務的存取控制)。
連線流量過慢此問題有下列徵兆：
- 訊息流量未符合預期速度。
- 支援連線至代理程式的數目不受到限制，如用戶端無法建立連線所述，但訊息輸入/輸出速率受到限制。
本節提供下列幾個可能原因：
網路連線或 WAN 太慢
確認此問題的原因
偵測網路，查看偵測到網路回應所需的時間，並洽詢網路管理員。您也可以使用本地用戶端傳送和接受訊息，並與遠端用戶端 (使用網路連結) 比較傳送時間。
若要解決此問題
如果連線過慢，請升級網路連結。
連線服務協定的速度原本就比 TCP 的速度慢
例如，SSL 型或 HTTP 型協定的速度會較 TCP 的速度慢 (請參閱圖 11-5)。
確認此問題的原因
如果您使用 SSL 型或 HTTP 型的協定，請嘗試使用 TCP 並比較傳送時間。
若要解決此問題
應用程式需求通常會表示要使用的協定，所以除了如調校傳輸協定所述嘗試調校協定外，還可以執行進行一些其他作業。
連線服務協定未調校到最佳化
確認此問題的原因
嘗試調整協定，並查看是否有何差異。
若要解決此問題
嘗試調整協定，如調校傳輸協定所述。
訊息過大導致使用過多的頻寬
確認此問題的原因
嘗試以較小訊息執行效能評定。
若要解決此問題
實際上，連線流量過慢的問題，是訊息傳送程序的某些步驟中會遇到的瓶頸
確認此問題的原因
如果上述原因都不是造成連線流量速度過慢的原因，則請查閱圖 11-1，找出其他可能的瓶頸，並檢查是否有與以下問題相關的徵兆：
若要解決此問題
依照以上問題排解各節提供的問題解決方案。
用戶端無法建立訊息產生者此問題有下列徵兆：
本節提供下列幾個可能原因：
已將實體目標配置為僅允許一定數目的產生者
若要防止實體目標上訊息累積，其中一個方法是限制實體目標可支援的產生者數目 (maxNumProducers)。
確認此問題的原因
檢查實體目標 (請參閱顯示實體目標資訊)：
imqcmd query dst
輸出會顯示目前的產生者數目和 maxNumProducers 的值。如果兩個值相同，表示產生者數目到達配置的限制。代理程式拒絕新的產生者時，代理程式會傳回 ResourceAllocationException [C4088]：到達 JMS 目標限制，且在代理程式記錄中產生以下項目：[B4183]：無法將產生者新增至目標。
若要解決此問題
增加 maxNumProducers 屬性的值 (請參閱更新實體目標特性)。
由於存取控制特性檔案中，未設定授權使用者建立訊息產生者
確認此問題的原因
代理程式拒絕新的產生者時，代理程式會傳回下列訊息：
代理程式也會在代理程式記錄中記錄下列項目：
若要解決此問題
變更存取控制特性，以允許使用者產生訊息 (請參閱實體目標的存取控制)。
訊息產生延遲或過慢此問題有下列徵兆：
本節提供下列幾個可能原因：
訊息伺服器進行儲存動作並且做出降低訊息產生者速度的回應
進行儲存動作的伺服器將訊息累積在代理程式記憶體中。
實體目標中的訊息數目或訊息容量到達配置限制時，代理程式會依指定的限制運作方式，嘗試節省記憶體資源。以下限制運作方式會降低訊息產生者的速度：
同樣地，整個代理程式記憶體 (用於所有實體目標) 中的訊息數目或訊息容量到達配置限制時，代理程式會藉由拒絕最新訊息，嘗試節省記憶體資源。
再者，到達系統記憶體限制時，因為實體目標或整個代理程式的限制未正確設定，所以代理程式會採取愈來愈重要的動作，以防記憶體超過負載。這些動作包括減低訊息產生者的速度。
確認此問題的原因
代理程式因配置的訊息限制拒絕訊息時，代理程式會傳回下列訊息：
代理程式也會在代理程式記錄中記錄此項目：
此訊息後面還有一則訊息指出已經到達限制。如果訊息限制位於實體目標上，則代理程式會產生類似以下的項目：
如果訊息限制為代理程式範圍，則代理程式會產生類似以下的項目：
一般而言，您可以在拒絕訊息前檢查訊息限制條件，方法為：
- 查詢實體目標和代理程式，檢查配置的訊息限制設定。
- 使用適當的 imqcmd 指令，監視目前實體目標或整體代理程式中的訊息數目或訊息容量。如需可監視的度量和度量取得指令的詳細資訊，請參閱第 18 章「度量參照」。
若要解決此問題
有數種方法可以解決訊息儲存時造成產生者速度變慢的問題。
一般來說，您應該在目標對目標層級上管理記憶體，如此一來，才永遠不會到達整個代理程式的訊息限制。如需更多資訊，請參閱代理程式調校。
例如，您可以指定可刪除記憶體中累積訊息的 REMOVE_OLDEST 和 REMOVE_LOW_PRIORITY 限制運作方式 (請參閱表 15-1)。
代理程式無法將永久性訊息儲存到資料存放區
如果代理程式無法存取資料存放區或將永久性訊息寫入資料存放區，則表示生產型用戶端被封鎖。這種情況亦會在目標或整個代理程式訊息到達限制時發生，如上所述。
確認此問題的原因
如果代理程式無法寫入資料存放區，則會在代理程式記錄中產生以下其中一個項目：[B2011]：儲存來自 connectionID 的 JMS 訊息失敗... 或 [B4004]：無法存留訊息 messageID?
若要解決此問題
- 在檔案型永久性的情況下，請嘗試增加檔案型資料存放區的磁碟空間。
- 在使用 JDBC 相容資料存放區的情況下，請檢查是否已正確配置 JDBC 型永久性 (請參閱第 4 章「配置代理程式」)。如果已正確配置，請洽詢您的資料庫管理員以排解其他資料庫問題。
代理程式確認逾時過短
由於連線速度慢或訊息伺服器緩慢 (因高 CPU 使用率或記憶體資源不足所引起)，代理程式可能需要更多時間來確認永久性訊息的接收，且時間超過連線工廠的 imqAckTimeout 屬性所允許的值。
確認此問題的原因
如果超過 imqAckTimeout 的值，代理程式會傳回下列訊息：
JMSException [C4000]：資料封包確認失敗
若要解決此問題
變更 imqAckTimeout 連線工廠屬性值 (請參閱可靠性和流量控制)。
生產型用戶端受到 JVM 限制
確認此問題的原因
若要解決此問題
調整 JVM (請參閱 Java 虛擬機器調校)。
儲存訊息此問題有下列徵兆：
本節提供下列幾個可能原因：
主題目標上有非使用中的長期訂閱
如果長期訂閱為非使用中，訊息會儲存在目標中，直到對應的用戶變為使用中狀態，且可使用這些訊息為止。
確認此問題的原因
檢查每個主題目標上的長期訂閱狀態：
imqcmd list dur -d destName
若要解決此問題
您可以採取以下任何動作：
佇列中可使用訊息的用戶太少
如果可傳送訊息的使用中用戶太少，則可以在訊息累積時儲存佇列目標。此情況會因以下任何一種原因而發生：
確認此問題的原因
若要判斷無法使用用戶的原因，請檢查目標上使用中用戶的數目：
imqcmd metrics dst -n destName -t q -m con
若要解決此問題
您可以根據無法使用用戶的原因，採取以下任何一個動作：
- 啟動其他用戶用戶端，以建立更多用於佇列的使用中用戶。
- 調整 imq.consumerFlowLimit 代理程式特性，以最佳化至多個用戶的佇列傳送 (請參閱多重用戶佇列效能)。
- 指定用於佇列的訊息限制和訊息運作方式屬性 (請參閱表 15-1)。例如，您可以指定可刪除記憶體中累積訊息的 REMOVE_OLDEST 和 REMIOVE_LOW_PRIOROTY 限制運作方式。
- 從對應的目標清除所有訊息 (請參閱清除實體目標)。
- 時間訊息的限制可保留在記憶體中。您可以重新寫入生產型用戶端，以設定每個訊息的存在時間值。另外，還可覆寫用於所有產生者共用連線的任何設定值，方法為設定 imqOverrideJMSExpiration 和 imqJMSExpiration 連線工廠屬性 (請參閱訊息標頭覆寫)。
訊息用戶處理速度過慢，無法跟上訊息產生者的速度
在此情況下，主題使用者或佇列接收者使用訊息的速度，會比產生者傳送訊息的速度慢。因為此不平衡現象，所以會儲存一個或多個包含訊息的目標。
確認此問題的原因
檢查傳入和傳出代理程式的訊息速率：
imqcmd metrics bkr -m rts
接著檢查每個個別目標的流量速率：
imqcmd metrics bkr -t destType -n destName -m rts
若要解決此問題
- 最佳化用戶用戶端程式碼。
- 增加用於佇列目標的使用中用戶數目 (請參閱多重用戶佇列效能)。
用戶端確認處理會降低訊息使用速度
兩個影響用戶端確認處理的因素：
確認此問題的原因
若要解決此問題
- 修改用戶端使用的確認模式，例如切換為 DUPS_OK_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE。
- 如果使用 CLIENT_ACKNOWLEDGE 或作業事件階段作業，請將更大的訊息數目設為單一確認的群組。
- 調整用戶和連線流量控制參數 (請參閱用戶端執行階段訊息流量調校)。
代理程式無法跟上產生訊息的速度
在此情況下，訊息傳入代理程式的速度，會比代理程式路由和派送訊息到用戶的速度快。代理程式運作遲緩可以是因為以下任何或所有限制造成：CPU、網路套接讀/寫作業、磁碟讀/寫作業、記憶體分頁、永久存放區或 JVM 記憶體限制。
確認此問題的原因
檢查是否有其他造成此問題的原因。
若要解決此問題
用戶端程式碼缺點：用戶不確認訊息
所有用戶確認傳送的訊息前，訊息會被保留在目標中。如果用戶端不確認使用的訊息，則訊息會累積在目標中且不被刪除。
舉例來說，用戶端程式碼可能會有以下缺點：
確認此問題的原因
首先，檢查本節中列出的所有其他可能原因。然後，使用下列指令，列出目標：
imqcmd list dst
請注意 [未確認] 標頭下列出的訊息數目，是否與目標中的訊息數目相同。[未確認] 標頭下的訊息是傳給用戶但尚未確認的訊息。如果這個數目與訊息總數相同，表示代理程式已經送出所有訊息，正在等待確認。
若要解決此問題
請應用程式開發者協助除錯此問題。
訊息伺服器的流量不穩定此問題有下列徵兆：
本節提供下列幾個可能原因：
代理程式在記憶體資源上的速度非常緩慢
因為未正確設定目標與代理程式限制，代理程式會採取越來越重要的動作，以防記憶體超過負載。另外，在清除訊息儲存前，會導致代理程式運作緩慢。
確認此問題的原因
檢查記憶體不足情況下的代理程式記錄 ([B1089]：在記憶體不足的條件下，代理程式正嘗試釋放資源)，並隨附一個項目，描述新的記憶體狀態和使用的記憶體總數。
還要檢查 JVM 堆疊中可用的記憶體：
imqcmd metrics bkr -m cxn
JVM 記憶體總數接近最大 JVM 記憶體值時，可用記憶體會不足。
若要解決此問題
- 調整 JVM (請參閱Java 虛擬機器調校)。
- 增加系統交換空間。
執行 JVM 記憶體收回 (廢棄項目收集)
會定期透過系統清除記憶體收回，釋放記憶體。發生此情況時，會阻塞所有執行緒。被釋放的記憶體容量越多，JVM 堆疊的大小就越大，且因記憶體收回的延遲時間也越長。
確認此問題的原因
監視您電腦的 CPU 使用情況。執行記憶體收回時，會大幅降低 CPU 使用。
再者，請使用以下指令行選項啟動代理程式：
-vmargs -verbose:gc
標準輸出說明執行記憶體收回的時間。
若要解決此問題
在多重 CPU 的電腦中，設定同時執行的記憶體收回：
-XX:+UseParallelGC=true
JVM 使用 Just-In-Time 編譯器來提高效能
確認此問題的原因
檢查是否有其他造成此問題的原因。
若要解決此問題
讓系統執行一段時間，效能應會改善。
訊息未送達用戶此問題有下列徵兆：
本節提供下列幾個可能原因：
限制運作方式導致訊息在代理程式上被刪除
目標記憶體中的訊息數目或訊息容量到達配置的限制時，代理程式嘗試節省記憶體資源。代理程式會配置三個可配置的運作方式，而到達這些限制時會使訊息遺失：
代理程式記憶體中的訊息數目或訊息容量到達配置限制時，代理程式藉由拒絕最新訊息，嘗試節省記憶體資源。
確認此問題的原因
如停用的訊息佇列中包含訊息 中所描述，檢查停用的訊息佇列。尤其要遵照訊息數目或訊息容量超出目標限制中的指示。尋找 REMOVE_OLDEST 或 REMOVE_LOW_PRIORITY 原因。
若要解決此問題
增加目標限制。例如：
imqcmd update dst -n MyDest -o maxNumMsgs=1000
訊息的逾時值過期
代理程式會刪除逾時值過期的訊息。如果目標儲存足夠的訊息，則可能會刪除存在時間值過短的訊息。
確認此問題的原因
檢查停用的訊息佇列有無訊息過期。
您可以使用 QBrowser 示範應用程式，查看 DMQ 內容。QBrowser 示範程式在作業系統的特定位置中，請參閱附錄 A「Message Queue 資料的平台特定位置」，查看「範例應用程式與位置」的表格。
這是 Windows 上的呼叫範例：
cd \MessageQueue3\demo\applications\qbrowser java QBrowser
QBrowser 主視窗出現時，請選取佇列名稱 mq.sys.dmq，然後按一下 [瀏覽]。會出現類似下面的清單。
圖 12-1 QBrowser 視窗
在訊息上連按兩下，即可顯示此訊息的詳細資訊。
圖 12-2 QBrowser 訊息的詳細資訊
請注意訊息的 JMS_SUN_DMQ_UNDELIVERED_REASON 特性值是否為 EXPIRED。
若要解決此問題
連絡應用程式開發者並增加存在時間值。
時鐘不同步
如果時鐘不同步，代理程式計算訊息的存在時間會發生錯誤，如此會導致訊息逾時並被刪除。
確認此問題的原因
查看代理程式記錄檔中有無下列訊息：B2102、B2103、B2104。這些訊息都報告偵測到時鐘可能不準。
解決問題
如準備系統資源中所述，檢查是否在執行時間同步化程式。
用戶用戶端無法啟動連線上的訊息傳送
用戶端程式碼建立連線並啟動連線上的訊息傳送前，將無法傳送訊息。
確認此問題的原因
檢查用戶端程式碼是否建立連線並啟動訊息傳送。
若要解決此問題
重新寫入用戶端程式碼，以建立連線並啟動訊息傳送。
停用的訊息佇列中包含訊息此問題有下列徵兆：
您提供使用者名稱和密碼後，會出現類似下面的輸出：
此範例中的停用的訊息佇列 mq.sys.dmq，包含 35 個訊息。
本節提供下列幾個可能原因：
訊息數目或訊息容量超出目標限制
確認此問題的原因
您可以使用 QBrowser 示範應用程式，查看停用的訊息佇列的內容。QBrowser 示範程式在作業系統的特定位置中，請參閱附錄 A「Message Queue 資料的平台特定位置」，查看「範例應用程式與位置」的表格。
這是 Windows 上的呼叫範例：
cd \MessageQueue3\demo\applications\qbrowser java QBrowser
QBrowser 主視窗出現時，請選取佇列名稱 mq.sys.dmq，然後按一下 [瀏覽]。出現 圖 12-1 中顯示的清單。
在任何訊息上連按兩下，即可顯示此訊息的詳細資訊。出現圖 12-2 中顯示的視窗。
請注意下列訊息特性值：
請注意 JMS 標頭下的 JMSDestination 值，判斷訊息將要停用的目標。
解決問題
增加目標限制。例如：
imqcmd update dst -n MyDest -o maxNumMsgs=1000
代理程式時鐘和產生者時鐘不同步
若要確認此問題的原因：
您可以使用 QBrowser 應用程式，在停用的訊息佇列中檢視訊息的詳細資訊。檢查 JMS_SUN_DMQ_UNDELIVERED_REASON 值，尋找原因為 EXPIRED 的訊息。
查看代理程式記錄檔中有無下列訊息：B2102、B2103、B2104。這些訊息都報告偵測到時鐘可能不準。
解決問題
如準備系統資源中所述，檢查有無執行時間同步化程式。
用戶在訊息逾時前一直未收到訊息
驗證此問題的原因
您可以使用 QBrowser 應用程式，在停用的訊息佇列中檢視訊息的詳細資訊。檢查 JMS_SUN_DMQ_UNDELIVERED_REASON 值，尋找原因為 EXPIRED 的訊息。
檢查目標上有無任何用戶。例如：
imqcmd query dst -t q -n MyDest
檢查列出的 [目前使用中的使用者數] 值。如果有使用中用戶，下列其中一項為 true：
若要解決此問題
請應用程式開發者增加訊息存在時間值。
產生者對用戶數目而言過多
確認此問題的原因
您可以使用 QBrowser 應用程式，在停用的訊息佇列中檢視訊息的詳細資訊。檢查 JMS_SUN_DMQ_UNDELIVERED_REASON 值。
如果原因是 REMOVE_OLDEST 或 REMOVE_LOW_PRIORITY，請使用 imqcmd query dst 指令，檢查目標上的產生者數目和用戶數目。如果產生者數目超過用戶數目，產生率可能高於使用率。
若要解決此問題
新增更多的用戶用戶端或設定目標使用 FLOW_CONTROL 限制運作方式。FLOW_CONTROL 限制運作方式是以使用率來控制產生率。
如下列範例所示，使用指令來啟動流量控制運作方式：
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
產生者的速度比用戶快
確認此問題的原因
若要判斷用戶速度慢是否導致產生者的速度變慢，請將目標限制運作方式設定為 FLOW_CONTROL。FLOW_CONTROL 限制運作方式是以使用率來控制產生率。
如下列範例所示，使用指令來啟動流量控制運作方式：
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
發出下列範例中的指令，使用度量來檢查目標的輸入與輸出：
imqcmd metrics dst -n myDst -t q -m rts
檢查度量輸出中的下列值：
流量控制會針對使用調整產生，注意產生速度是否變慢或停止。如果產生率變慢或停止，表示產生者和用戶的處理速度有差異。
您也可以使用 imqcmd list dst 指令，檢查已傳送的未確認訊息數目。如果未確認的訊息數目小於目標容量，表示目標還有其他容量被用戶端的流量控制所控制。
若要解決此問題
如果要產生率一直快於使用率，請考慮定期使用流量控制讓系統步調一致。
後續幾節介紹如何解決下面的可能因素：
用戶的速度太慢
確認此問題的原因
如產生者的速度比用戶快中所描述，使用度量來判斷產生率和使用率。
若要解決此問題
嘗試下列一種或多種操作：
- 設定目標使用 FLOW_CONTROL 限制運作方式。您可以使用類似下面的指令：
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
使用流量控制讓產生率不超過使用率，防止代理程式上的訊息累積。產生者應用程式會保留訊息，直到目標可以及時處理為止，降低過期風險。
- 向應用程式開發者詢問產生者是以固定的速率傳送訊息或是定期以某資料量傳送。
如果應用程式是依資料量傳送訊息，請按照下一個項目的指示，增加目標限制。
- 根據訊息的數目和/或位元組，增加目標限制。
若要變更目標的訊息數目，請輸入下列格式的指令：
imqcmd update dst -n destName -t {q/t} -o maxNumMsgs=number
用戶端未確定訊息
確認此問題的原因
向應用程式開發者查詢應用程式是否使用作業事件。如果應用程式使用作業事件，請如下所示列出使用中作業事件：
imqcmd list txn
下面是指令的輸出範例：
----------------------------------------------------------------------
作業事件 ID 狀態 使用者名稱 訊息數目/確認數目 建立時間
----------------------------------------------------------------------
6800151593984248832 STARTED guest 3/2 7/19/04 11:03:08 AM
請注意訊息和確認的數目。
如果訊息數目大於確認數目，表示產生者可能有傳送個別訊息，但卻無法確定作業事件。代理程式收到確定後，才能路由並傳送該項作業事件的訊息。
如果確認數目大於訊息數目，表示用戶可能有傳送個別訊息，但卻無法確定作業事件。代理程式收到確定後，才能移除該項作業事件的確認。
解決問題
請連絡應用程式開發者，修正程式碼錯誤。
用戶無法確認訊息
確認此問題的原因
連絡應用程式開發者，判斷應用程式使用系統型或用戶端型的確認。如果應用程式使用系統型的確認，請略過本節。
如果應用程式用戶用戶端型的確認 (CLIENT_ACKNOWLEDGE 類型)，請先減少用戶端上儲存的訊息數目。您可以使用類似下面的指令：
imqcmd update dst -n myDst -t q -o consumerFlowLimit=1
接著判斷代理程式緩衝訊息是因為用戶的速度太慢，還是用戶處理訊息的速度很快，但確認的速度不快。
使用下列指令，列出目標：
imqcmd list dst
您提供使用者名稱和密碼後，會出現類似下面的輸出：
列出指定代理程式上的所有目標：
---------------------------------
主機 主要連接埠
---------------------------------
localhost 7676
----------------------------------------------------------------------
名稱 類型 狀態 產生者 用戶 訊息 未確認 平均
總數 大小
-----------------------------------------------------------------------
MyDest Queue 執行中 0 0 5 200 1177.0
mq.sys.dmq Queue 執行中 0 0 35 0 1422.0
成功地列示目標。
未確認數目代表代理程式傳送出去後等待確認的訊息數目。如果未確認數目變大或增加，表示代理程式正在傳送訊息，不等速度較慢的用戶。您也可以看出用戶未確認訊息。
若要解決此問題
請連絡應用程式開發者，修正程式碼錯誤。
長期用戶處於非使用中
確認此問題的原因
使用下面的指令格式，查看主題的長期用戶：
imqcmd list dur -d topicName
若要解決此問題
發生非預期的代理程式錯誤
確認此問題的原因
如產生者的速度比用戶快中所描述，使用 QBrowser 檢查訊息。
如果 JMS_SUN_DMQ_UNDELIVERED_REASON 值是 ERROR，表示代理程式發生錯誤。
若要解決此問題
