メッセージがバックログされる

症状:

• メッセージの生成が遅い、または生成されたメッセージがブローカによって拒否される。

• メッセージがコンシューマに到達するまでに異常に長い時間がかかる。

• ブローカまたは特定の送信先のメッセージ数またはメッセージのバイト数が時間の経過とともに徐々に増えていく。

メッセージが蓄積されているかどうかを確認するため、ブローカ内のメッセージ数またはメッセージのバイト数が時間の経過とともにどのように変化するかを確認し、設定済みの制限と比較します。最初に、設定済みの制限を確認します。

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

問題を解決するには:

• コンシューミングクライアントコードを最適化します。

• キュー送信先の場合は、アクティブなコンシューマの数を増やします (「複数のコンシューマキューのパフォーマンス」を参照)。

考えられる原因: クライアントの通知処理が、メッセージの消費を遅くする。

クライアントの通知処理には 2 つの要因が影響しています。

• クライアント通知の処理時に、大量のブローカリソースが使用されることがあります。その結果、このような通知モードでは、ブローカがクライアント通知を確認するまでコンシューミングクライアントがブロックされるので、メッセージの消費が遅くなることがあります。

• JMS ペイロードメッセージと、クライアント通知などの Message Queue 制御メッセージは同じ接続を共有します。その結果、制御メッセージが JMS ペイロードメッセージによって保留され、メッセージの消費を低速化させることがあります。

この問題の原因を確認するには:

• メッセージのフローをパケットのフローと比較して確認します。1 秒当たりのパケット数がメッセージの数と比例していない場合は、クライアントの通知が問題と考えられます。

• クライアントが次の例外を受信したかどうかを確認します。

  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」の下に一覧表示されるメッセージの数が、送信先のメッセージの数と同じであるかどうか確認してください。このヘッダーの下のメッセージはコンシューマに送信されますが、通知されません。この数がメッセージの総数と同じである場合、ブローカはすべてのメッセージを送信し、通知を待機しています。

問題を解決するには: アプリケーション開発者にこの問題をデバッグしてもらうように依頼します。