test

Sun Java System Message Queue 3.7 UR1 管理ガイド

デッドメッセージキューにメッセージが含まれる

症状: 


Listing all the destinations on the broker specified by:

---------------------------------

Host         Primary Port

---------------------------------

localhost    7676

----------------------------------------------------------------------

   Name     Type    State   Producers  Consumers  Msgs

                                         Total    Count  UnAck  Avg Size

------------------------------------------------- ----------------------

MyDest      Queue  RUNNING       0          0        5      0    1177.0

mq.sys.dmq  Queue  RUNNING       0          0       35      0    1422.0

Successfully listed destinations.

この例では、デッドメッセージキュー mq.sys.dmq に 35 個のメッセージが含まれています。

考えられる原因:

考えられる原因: メッセージ数かメッセージサイズが送信先の制限を超える。

この問題の原因を確認するには: QBrowser デモアプリケーションを使用し、デッドメッセージキューの内容を調べます。QBrowser デモのプラットフォームごとの場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照し、アプリケーション例と場所の表を調べてください。

次に示すのは、Windows プラットフォームにおける呼び出し例です。

cd \MessageQueue3\demo\applications\qbrowser java QBrowser

QBrowser のメインウィンドウが表示されたら、キュー名 mq.sys.dmq を選択してから「Browse」をクリックします。前に「メッセージタイムアウト値が期限切れになる」に示したようなリストが表示されます。メッセージをダブルクリックすると、そのメッセージの詳細が表示されます。「メッセージタイムアウト値が期限切れになる」で示したウィンドウが表示されます。

次のメッセージプロパティーの値を確認してください。

「JMS Headers」の下で 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

Current Number of Active Consumers に一覧表示される値を確認します。アクティブなコンシューマがある場合は、次のうちいずれかに該当します。

問題を解決するには: アプリケーション開発者に、メッセージの生存時間の値を上げてもらいます。

考えられる原因: コンシューマの数に対してプロデューサが多すぎる。

この問題の原因を確認するには: QBrowser アプリケーションを使用し、デッドメッセージキューのメッセージのメッセージ詳細を表示します。JMS_SUN_DMQ_UNDELIVERED_REASON の値を確認します。この値が REMOVE_OLDEST か REMOVE_LOW_PRIORITY である場合は、imqcmd query dst コマンドを使用し、送信先のプロデューサ数とコンシューマ数を確認します。プロデューサ数がコンシューマ数より多い場合は、生成レートが消費レートを超えている可能性があります。

問題を解決するには: コンシューマクライアントを追加するか、または、次のようなコマンドを使用して、送信先の制限動作を FLOW_CONTROL (消費レートを使用して生成レートを制御する) に設定します。

imqcmd update dst -n myDst -t q -o consumerFlowLimit=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 コマンドを使用し、未通知 (UnAcked) 送信メッセージの数を確認することもできます。未通知メッセージ数が送信先のサイズより小さい場合、送信先では容量に余裕がありますが、送信先はクライアントフロー制御によって抑制されています。

問題を解決するには: 生成レートが消費レートより常に速い場合は、フロー制御を定期的に使用することを考慮し、システムを調整します。また、後続の節を参照し、次の考えられる要因の解決を考慮するか試してください。

考えられる原因: コンシューマが遅すぎる。

この問題の原因を確認するには: 「プロデューサがコンシューマより速い」の説明に従い、メトリックスを使用して、生成と消費のレートを判断します。

問題を解決するには:

考えられる原因: クライアントがメッセージをコミットしない。

この問題の原因を確認するには: アプリケーション開発者と協力し、アプリケーションでトランザクションが使用されているかどうかを調べます。使用されている場合は、次のようにアクティブなトランザクションを一覧表示します。

imqcmd list txn

以下は、コマンド出力の例です。


----------------------------------------------------------------------

Transaction ID       State    User name  # Msgs/# Acks   Creation time

----------------------------------------------------------------------

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

ユーザー名とパスワードを入力したあとで、次のような出力が表示されます。


Listing all the destinations on the broker specified by:
---------------------------------
Host         Primary Port
---------------------------------
localhost    7676
----------------------------------------------------------------------
   Name     Type    State   Producers  Consumers  Msgs
                                         Total    Count  UnAck  Avg Size
------------------------------------------------ -----------------------
MyDest      Queue  RUNNING       0          0        5    200    1177.0
mq.sys.dmq  Queue  RUNNING       0          0       35      0    1422.0
Successfully listed destinations.

UnAck の数値は、ブローカが送信して通知を待機しているメッセージ数を表します。この数値が高いか上昇し続けている場合、ブローカはメッセージを送信しているので、遅いコンシューマを待機していません。コンシューマはメッセージを通知していないことになります。

問題を解決するには: アプリケーション開発者に連絡し、コーディングエラーを修正します。

考えられる原因: 永続コンシューマがアクティブにならない。

この問題の原因を確認するには: 次のコマンド形式を使用し、トピックの永続サブスクライバを調べます。

imqcmd list dur -d topicName

問題を解決するには:

考えられる原因: 予期しないブローカエラーが発生する。

この問題の原因を確認するには: 「プロデューサがコンシューマより速い」の説明に従い、QBrowser を使用してメッセージを調べます。 JMS_SUN_DMQ_UNDELIVERED_REASON の値が ERROR である場合は、ブローカエラーが発生しています。

問題を解決するには: