パブリッシュ/サブスクライブ・メッセージがリモート・メッセージ・ポイントを経由してサブスクリプションにより受信されていない理由の調査

パブリッシュ/サブスクライブ・メッセージがリモート・メッセージ・ポイントを経由してルーティングされている場合に、そのメッセージがサービス統合バス上のサブスクリプションにより受信されていない理由を調査するために実行できる一連の検査があります。

始める前に

パブリッシュ/サブスクライブ・メッセージがサブスクリプションに到着しない理由の調査に記載されたステップに従います。 そこには、このタスクを進める前に実行する必要のある、事前確認および調査タスクが記載されています。

このタスクについて

このタスクは、パブリッシュ/サブスクライブ・メッセージがサブスクリプションに到着しない理由の調査 の一部として実行します。 このタスクでは、メッセージがリモート・メッセージ・ポイントを経由して非永続サブスクリプションにルーティングされているパブリッシュ/サブスクライブ・メッセージング・シナリオにおいて、メッセージのフローを調査する方法について説明します。 以下の図には、考えられる 2 つの状態が示されています。 図において、点線は公開ポイント間の関係を表し、実線はメッセージのフローを表しています。 図 1 では、バスに 3 つのメッセージング・エンジン、ME1、ME2、および ME3 が 含まれています。パブリッシュ・アプリケーションは ME1 に接続され、サブスクライブ・アプリケーションは ME2 および ME3 に接続されています。ME1 は、ME2 および ME3 によりホストされた公開ポイントを表す、リモート公開ポイントをホストします。 図 2 では、バスに 3 つのメッセージング・エンジン、ME1、ME2、および ME3 が 含まれています。パブリッシュ・アプリケーションは ME1 に接続され、サブスクライブ・アプリケーションは ME2 および ME3 に接続されています。 ME1 は、ME2 および ME3 によりホストされた公開ポイントを表す、リモート公開ポイントをホストします。 サブスクライブ・アプリケーション B は ME3 に接続され、ME2 上のリモート・サブスクリプションを経由して パブリケーションを受信します。メッセージング・エンジンは、以下のステップで参照されます。
図 1. リモート・メッセージ・ポイントを使用した point-to-point メッセージ生成この図は、リモート・メッセージ・ポイントを使用した point-to-point メッセージ生成を示しています。
図 2. リモート・メッセージ・ポイントを使用したパブリッシュ/サブスクライブ・メッセージングこの図は、リモート・メッセージ・ポイントを使用したパブリッシュ/サブスクライブ・メッセージングを示しています。
以下のステップは、上記のシナリオの両方に適用されます。

手順

  1. サービス統合 ->「バス」 -> 「bus_name -> [トポロジー (Topology)]「メッセージング・エンジン (Messaging engines)」 ->「engine_nameをクリックして、ME1 のプロパティーを表示します。
  2. ME1 の「ランタイム」タブで、「[リモート・メッセージ・ポイント] リモート公開ポイント」 をクリックし、ME2 上の公開ポイントを表すリモート公開ポイントをクリックします。「トピック」をクリックして、コンシューマーのトピックがリストされているか確認します。 トピックがリストされていない場合は、以下の確認を実行します。
  3. サブスクリプションの登録が、メッセージのパブリッシュ後に行われた可能性があります。 メッセージをリパブリッシュし、受信されたか再度確認します。
  4. ME1 で、再度 ME2 上の公開ポイントを表すリモート公開ポイントを表示します。 「現在のアウトバウンド・メッセージ数」フィールドの値を確認します。
  5. 現行アウトバウンド・メッセージの数がゼロより大きい場合、メッセージは生成されていますが、ME2 で受信されていない可能性があります。
    1. 2 つのメッセージング・エンジンが相互に通信可能であることを確認します。 サービス統合のトラブルシューティング: バス内の 2 つのメッセージング・エンジン間通信の検査を参照してください。
    2. トピック・スペースで以前のメッセージを探します。 以前のメッセージがあり、その一部またはすべてが ME2 に対するものである場合は、少し待ってからビューを最新表示します。
      • 一部のメッセージがトピック・スペースから消えている場合、システムは現在メッセージを配信中ですが、バックログがあります。 バックログがクリアされるまで待ち、次に ME2 の公開ポイントを検査して、テスト・メッセージが到着しているかどうか確認します。
      • トピック・スペースからメッセージが消えていない場合は、メッセージの送信が、コミット中状態でトラップされたメッセージによりブロックされている可能性があります。 後のメッセージは、このメッセージが配信されるまで待つ必要があります。 そのようにしないとメッセージの順序が壊れてしまいます。

        メッセージが「コミット中」状態でトラップされている場合、そのメッセージは未解決のトランザクションに含まれています。 データベースなどのリソース・マネージャーがハングした可能性があります。 リソース・マネージャーにおける問題を解決してください。 問題が解決しない場合は、メッセージの「トランザクション ID」をメモし、「サーバー」 ->「サーバー・タイプ(Server Types)」 ->「WebSphere Application Server (WebSphere application servers)」 -> 「server_name ->「ランタイム」 > [追加プロパティー]「トランザクション・サービス」をクリックして、トランザクション・サービスの一般プロパティーを表示します。「検討」リンクを使用して、「グローバル ID」がメッセージのトランザクション ID と一致するトランザクションを解決します。

    3. 以下のように、テスト・メッセージの状態を検査します。
      • テスト・メッセージの状況が「送信の保留」である場合、 メッセージは送信されるのを待っています。ME2 がメッセージを受信していない可能性があります。 以下の確認を行ってください。
        • 2 つのメッセージング・エンジンが相互に通信可能であるか確認します。 サービス統合のトラブルシューティング: バス内の 2 つのメッセージング・エンジン間通信の検査を参照してください。
        • ME2 の公開ポイントがフルでないことを確認します。 公開ポイントのランタイム・プロパティーを表示し、「現行メッセージの深さ」「メッセージの高しきい値」を比較します。 現行メッセージの深さがメッセージの高しきい値と等しい場合、メッセージング・エンジンは、キューに入れられたメッセージがコンシュームされるまで、新しいメッセージを受け入れません。 コンシューマーを再始動してバックログがクリアされるまで待つか、メッセージを削除します。
        • 構成の変更が伝搬されているか確認します。 ME2 のアプリケーション・サーバーに最新の構成設定をデプロイすることにより、ME2 に公開ポイントの存在を確実に認識させます。
      • テスト・メッセージの状況が「確認応答の保留」である場合、 メッセージの送信は完了していますが、ME2 がメッセージを受信していないか、 メッセージを処理していません。送信キューにおいてテスト・メッセージの前にコミット中状態のメッセージがないことを確認し、次に少し待ってから公開ポイントを再度検査して、テスト・メッセージが到着しているか確認します。コミット中状態でトラップされたメッセージがある場合は、以下のポイントを参照することによりこの問題を解決します。
      • テスト・メッセージ (または他のメッセージ) が「コミット中」状態にある場合、 そのメッセージは未解決のトランザクションに含まれています。データベースなどのリソース・マネージャーがハングした可能性があります。 リソース・マネージャーにおける問題を解決してください。 問題が解決しない場合は、メッセージの「トランザクション ID」をメモし、「サーバー」 ->「サーバー・タイプ(Server Types)」 ->「WebSphere Application Server (WebSphere application servers)」 -> 「server_name ->「ランタイム」 > [追加プロパティー]「トランザクション・サービス」をクリックして、トランザクション・サービスの一般プロパティーを表示します。「検討」リンクを使用して、「グローバル ID」がメッセージのトランザクション ID と一致するトランザクションを解決します。
  6. 完了したアウトバウンド・メッセージの数がゼロより大きい場合、メッセージは生成され ME2 により処理されていますが、テスト・メッセージは現れていません。 プロデューサー・アプリケーションを再実行して、ME1 上の完了したアウトバウンド・メッセージの数が増加することを確認します (完了したアウトバウンド・メッセージ数が増加する前に、活動中のアウトバウンド・メッセージ数が増加することを確認できます)。
    • その数が増加しない場合は、メッセージが ME1 で生成されていません。 プロデューサー・アプリケーションが、このメッセージング・エンジンに接続されていることを確認します (アプリケーションが接続されているメッセージング・エンジンの判別を参照してください)。
    • その数が増加する場合は、メッセージは ME2 に到着していますが、コンシューム済みであるか、例外の宛先に送信されたか、または期限切れになっています。 コンシューマーが存在するか確認して、事前確認を再度実行します。
  7. 現行および完了メッセージの数が両方ともゼロである場合は、関連する事前確認を再度実行することにより、プロデューサー・アプリケーションがこの宛先へのメッセージを生成しているか確認します。
  8. これで、ME1 と ME2 の間のメッセージのフローが確認されました。 図 1 のサブスクライブ・アプリケーション A または B の位置にあるアプリケーションがある場合、この状態は完全に調査されたことになります。 問題が解決されない場合は、IBM 技術員に連絡してください。 図 2 のサブスクライブ・アプリケーション B の位置にあるアプリケーションがある場合、つまり、リモート・サブスクリプションがあるアプリケーションがある場合は、以下のステップを使用して、ME2 と ME3 の間のメッセージのフローも調査する必要があります。 ご使用のアプリケーションがリモート・サブスクリプションを使用しているかどうか判別するには、関連するトピック・スペースの公開ポイントを表示して、ご使用のサブスクリプションを探し、公開ポイントの名前を確認します。 その名前は topic_space_name@messaging_engine_name という形式です。 これにより、サブスクリプションをホストしているメッセージング・エンジンがわかります。 このメッセージング・エンジンが、プロデューサー・アプリケーションが接続されたメッセージング・エンジン、およびコンシューマー・アプリケーションが接続されたメッセージング・エンジンのどちらとも異なる場合は、リモート・サブスクリプションが使用されています。
  9. ME2 上の公開ポイントに対するサブスクリプションを表示し、リストでご使用のサブスクリプションを探します。 サブスクリプションがリストされていない場合は、以下の確認を実行します。
  10. ご使用のサブスクリプションをクリックして、「Known remote subscription points」をクリックします。 結果のリストで、図に ME3 として表されているメッセージング・エンジンの名前をクリックします。 「Message requests」をクリックします。 これにより、ME2 上のサブスクリプションが ME3 上のリモート・サブスクリプションから受信した要求が表示されます。
  11. 可能で あれば、コンシューマー・アプリケーションを開始し、それが メッセージをアクティブにコンシュームしようとしている (アプリケーションは「待機して受信」状態または「非同期コンシューマー登録済み」状態のいずれかでなければなりません) ことを確認した後、 アプリケーションの実行時に、 リモート・メッセージ・ポイントまたはサブスクリプション・ポイントを経由してメッセージがコンシュームされていない理由の調査に記述されている指示に従います。 アプリケーションが、有効な期間 (問題の調査に十分な期間) アクティブなコンシューム状態を保てない場合は、 アプリケーションの停止時に、リモート・メッセージ・ポイントまたはサブスクリプション・ポイントを経由してメッセージがコンシュームされていない理由の調査に記載されているステップに従ってください。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tju_pubsub_nd_remote
ファイル名:tju_pubsub_nd_remote.html