トピック・スペースがフルである理由の調査
トピック・スペースがフルになった場合、そのトピック・スペースに対してメッセージをパブリッシュしようとすると、例外が戻されます。 トピック・スペースがフル状態になるもっともありうる理由は、パブリッシュ・アプリケーションが、サブスクライブ・アプリケーション (複数可) がコンシュームできるよりも速くメッセージを生成していることです。 ただし、休止のサブスクライバーや通信リンク障害など、別の原因の場合もあります。 もう一つの考えられる原因として、例えば 1 日の特定の時刻などでの、通常のメッセージ・トラフィックの増加があります。 メッセージの高しきい値を引き上げてこの問題に対処することを考慮してみてください。
このタスクについて
手順
- サービス統合 ->「バス」 -> 「bus_name」 -> [宛先リソース (Destination resources)]「宛先 (Destinations)」をクリックして、そのバス上のすべてのトピック・スペースが含まれたリストを表示します。フルになっているトピック・スペースの名前をクリックします。
- 「[メッセージ・ポイント] 公開ポイント」をクリックします。
- 公開ポイントの名前をクリックして、「ランタイム」タブ上の「現行メッセージの深さ」の値を確認します。この値が絶え間なく増加する場合は、パブリッシュ・アプリケーションのペースがサブスクライバーを上回っています。
「サブスクリプション」をクリックして、そのトピック・スペースのサブスクリプションを表示します。
それぞれのサブスクリプションごとにサブスクリプション名をクリックして、「現行メッセージの深さ」を確認します。
すべてのサブスクリプションがフルになっている場合は、パブリッシュ・アプリケーションがメッセージをパブリッシュする速度を落とします。 注: そのトピック・スペースが仲介されている場合は、メッセージの送信先または利用元であるそれぞれのメディエーション・ポイントごとに、以下の確認を実行します。
- 1 つのサブスクリプションのみがフルになっている場合、問題は関連するサブスクライブ・アプリケーションにあります。 サブスクリプションが非永続である場合は、サブスクライブ・アプリケーションを変更して、コンシューム速度を上げます。
- そのサブスクリプションが永続サブスクリプションである場合は、「メッセージ」をクリックして、リストの先頭にあるメッセージが時間とともに変化することを確認します。 これは、サブスクライブ・アプリケーションがメッセージをコンシュームしていることを示しています。 メッセージは変化しないが、アプリケーションが実行中である場合は、そのサブスクリプションを削除するか、または公開ポイントのメッセージの高しきい値を引き上げます。
- どのメッセージング・エンジンにパブリッシュ・アプリケーションおよびサブスクライブ・アプリケーションが接続されているかを判別します。 アプリケーションが接続されているメッセージング・エンジンの判別を参照してください。
- パブリッシュ・アプリケーションおよびサブスクライブ・アプリケーションが別々のメッセージング・エンジンに接続されている場合、メッセージはリモート・キュー・ポイントを介してルーティングされています。
パブリッシャーのメッセージング・エンジンで「Remote publication points」をクリックし、次にサブスクライバーのパブリッシュ・ポイントを表すパブリッシュ・ポイントをクリックします。
現在のアウトバウンド・メッセージの数を確認します。
現在のメッセージ数が少ない場合、リモート・メッセージ・ポイントに問題はありません。
現在のメッセージ数がメッセージの高しきい値に近づいている場合は、以下の確認を実行します。
- 2 つのメッセージング・エンジンが相互に通信可能であるか確認します。
サービス統合のトラブルシューティング: バス内の 2 つのメッセージング・エンジン間通信の検査を参照してください。 メッセージング・エンジンが通信できる場合は、メッセージをパブリッシュする速度を落とします。
メッセージング・エンジンが通信できない場合は、障害を解決します。
通信が回復した後にメッセージのバックログの処理で問題が発生した場合、そのバックログに重要なメッセージが含まれていないのであれば、そのリモート・メッセージ・ポイント上のすべてのメッセージを削除することを考慮してみてください。
メッセージを削除するには、関連するリモート・メッセージ・ポイントを選択して、「Delete all messages」をクリックします。
注: メッセージは削除されると、リカバリーできません。メッセージが再度作成されないようにするには、「トピック」をクリックして、「全消去」をクリックします。 このリモート公開ポイントに、メッセージはこれ以上送信されません。 トピック・リストをリセットするには、メッセージング・エンジンを再始動します。
- メッセージが「コミット中」状態でトラップされていないことを確認します。 その状態でトラップされた場合は、データベースなどのリソース・マネージャーがハングしています。 リソース・マネージャーにおける問題を解決してください。 問題が解決しない場合は、メッセージの「トランザクション ID」をメモし、「サーバー」 ->「サーバー・タイプ(Server Types)」 ->「WebSphere Application Server (WebSphere application servers)」 -> 「server_name」 ->「ランタイム」 > [追加プロパティー]「トランザクション・サービス」をクリックして、トランザクションの数を含む、トランザクション・サービスの一般プロパティーを表示します。「Review」リンクを使用して、「グローバル ID」がメッセージのトランザクション ID と一致するトランザクションを解決します。
- 2 つのメッセージング・エンジンが相互に通信可能であるか確認します。
サービス統合のトラブルシューティング: バス内の 2 つのメッセージング・エンジン間通信の検査を参照してください。 メッセージング・エンジンが通信できる場合は、メッセージをパブリッシュする速度を落とします。
メッセージング・エンジンが通信できない場合は、障害を解決します。
通信が回復した後にメッセージのバックログの処理で問題が発生した場合、そのバックログに重要なメッセージが含まれていないのであれば、そのリモート・メッセージ・ポイント上のすべてのメッセージを削除することを考慮してみてください。
メッセージを削除するには、関連するリモート・メッセージ・ポイントを選択して、「Delete all messages」をクリックします。
サブトピック
アプリケーションが接続されているメッセージング・エンジンの判別
アプリケーションがメッセージの受信または生成に失敗する場合、問題のトラブルシューティングの一部として、その接続先のメッセージング・エンジンを知る必要がある場合があります。サービス統合のトラブルシューティング: バス内の 2 つのメッセージング・エンジン間通信の検査
サービス統合システムにおける問題をトラブルシューティングしている場合、2 つのメッセージング・エンジンが相互に通信可能か、確認が必要な場合があります。


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tju_topicspace_full
ファイル名:tju_topicspace_full.html