4 FAQ : WebLogicメッセージング・ブリッジ

この章では、WebLogicメッセージング・ブリッジに関するよくある質問(FAQ)に対する回答を紹介します。

この章の内容は次のとおりです。

メッセージング・ブリッジによるソース・ブリッジ宛先への接続が失敗したのはなぜですか。

ソース・ブリッジ宛先のパラメータの構成でエラーが発生したか、実際のソース宛先が動作しておらずメッセージング・ブリッジと通信できないかのいずれかと考えられます。

  • ブリッジのソース宛先が正しく構成されているかどうかを確認します。そのためには、「JMSブリッジ宛先構成」ページで次のフィールドを確認します:

    • 「接続URL」 - 接続ファクトリおよび実際の宛先のルックアップに使用するJNDIプロバイダのURL。

    • 「宛先のJNDI名」 - ソース・ブリッジ宛先にマップされた実際の宛先のJNDI名。

    • 「接続ファクトリのJNDI名」 - ソース・ブリッジ宛先にマップされた実際の宛先に対する接続を作成するために使用する接続ファクトリ。

    • 「ユーザー名」/「パスワード」 - 実際のソース宛先にアクセスするためのパーミッションを持つユーザー。

  • ソース・ブリッジ宛先にマップされた実際のソース・キューまたはトピック宛先が正常に動作しているかどうかについて、次の点を確認します。

    • ソース宛先をホストするWebLogic Serverインスタンスは動作しているか。

    • ソース宛先をホストするJMSサーバーは正しくデプロイされているか。

      ノート:

      ここではソース・ブリッジ宛先の接続障害を想定していますが、ターゲット・ブリッジ宛先の接続障害にもこの手順を適用できます。

一部のメッセージが転送されないのはなぜですか。

通常、メッセージング・ブリッジはすべてのメッセージを転送します。一部のメッセージが転送されない場合は次の理由が考えられます。

  • 一部のメッセージに有効期限がある場合、ソース宛先またはターゲット宛先のJMSプロバイダによりメッセージが失効します。

  • セレクタ・フィルタを指定するようにブリッジ・ソース宛先を構成した場合、フィルタ処理されたメッセージのみが転送されます。

  • ブリッジでは、転送の制限回数を超えた場合、メッセージをエラー宛先に自動で移動したり、自動で削除したりするオプションは直接提供されません。ただし、JMSプロバイダには、ブリッジ・ソース宛先でメッセージに関する同様の機能をもたらすオプションがあります。ブリッジ・ソース宛先をホストするJMSプロバイダで再配信制限オプションが有効な場合、ブリッジの自動再試行メカニズムがメッセージの再配信制限を超えないようにプロバイダを再構成することを検討してください。

メッセージング・ブリッジで、別個のWeblogic Serverドメイン間または異なるリリース間の2フェーズ・トランザクションやグローバル・トランザクションを処理できますか。

はい - 「WebLogic Serverの別のリリースとの相互運用」を参照してください。

メッセージング・ブリッジが動作するドメインにトランザクションjms-xa-adp.rarリソース・アダプタをデプロイしましたが、まだ「ブリッジ・アダプタが見つかりませんでした」というメッセージが表示されます。

ブリッジがソース・ブリッジ宛先およびターゲット・ブリッジ宛先と通信できるようにするには、それぞれの宛先を適切な.rarアダプタに関連付けます。jms-xa-adp.rarトランザクション・アダプタの場合は、ソース・ブリッジ宛先およびターゲット・ブリッジ宛先の「JMSブリッジ宛先:構成」タブの「アダプタのJNDI名」属性でeis.jms.WLSConnectionFactoryJNDIXAとして識別される必要があります。

ノート:

「ブリッジ・アダプタが見つかりませんでした」のメッセージが1回だけ表示される場合、特に問題がないこともあります。しかし、このメッセージが繰返し表示される場合は、アダプタのデプロイメントと、ソース・ブリッジ宛先およびターゲット・ブリッジ宛先で使用されているアダプタのJNDI名を確認する必要があります。

ブリッジ・リソース・アダプタの詳細は、「リソース・アダプタ」を参照してください。

メッセージング・ブリッジのソース宛先または対象宛先を構成する際に、「アダプタ・クラス・パス」フィールドを設定する必要はありますか。

ソース宛先およびターゲット宛先が両方ともWebLogic Serverインスタンスで動作している場合、「アダプタ・クラス・パス」フィールドは空白のままにします。サード・パーティのJMSプロバイダに接続する場合、ブリッジ宛先はWebLogic ServerのCLASSPATHにそのプロバイダのCLASSPATHを指定する必要があります。

メッセージング・ブリッジのデバッグを有効にするにはどうすればよいですか。

メッセージング・ブリッジのデバッグは、以下のいずれかの方法で有効にできます。

  • WebLogic起動スクリプトに以下の行を追加する(weblogic.Server行の前)。

    -Dweblogic.debug.DebugMessagingBridgeStartup=true
    -Dweblogic.debug.DebugMessagingBridgeRuntime=true
  • メッセージング・ブリッジが動作しているサーバーの構成ファイル(config.xml)で、ServerDebugエントリに以下の文を追加します。

    DebugMessagingBridgeStartup="true"
    DebugMessagingBridgeRuntime="true"
    

メッセージング・ブリッジのデバッグを有効にすると、デバッグ・メッセージはデフォルトではサーバー・ログに送信されます。

メッセージング・ブリッジで、ソース宛先やターゲット宛先として分散宛先を使用できますか。

はい。メッセージング・ブリッジを使用して、分散宛先との間で送受信できます。以下の構成をお薦めします。

  • ソース宛先が分散宛先の場合、ブリッジは宛先に接続したときにいずれかの宛先メンバーに固定されます。ブリッジは、再接続するまでそのメンバーのみに接続し続けます。分散宛先の他のメンバーからのメッセージは受信しません。そのため、メンバーのJNDINameを使用して、分散宛先の各メンバーに1つずつブリッジを構成するのが最適です。

  • ターゲットが分散宛先の場合、ベスト・プラクティスは、分散宛先のJNDINameを使用して分散宛先に対して送信し、サーバー・アフィニティを無効にしておくことです。こうすると、分散宛先で受信するメッセージをロード・バランシングできます。

メッセージング・ブリッジをモニターする別の方法はありますか。

各ブリッジ・インスタンスの実行時MBean (MessagingBridgeRuntimeMBean)を使用する方法があります。WebLogic Serverの実行時MBeanでは、ドメイン・リソースに関する特定の時点での情報が提供されます。ドメインの特定のリソース(メッセージング・ブリッジなど)がインスタンス化されると、そのリソースについての情報を収集するMBeanのインスタンスが作成されます。

MessagingBridgeRuntimeMBeanには、現時点でString (「Active」または「Inactive」)を返すgetState()メソッドと、より詳細な情報が格納されたStringを返すgetDescription()メソッドがあります。ブリッジ実行時MBeanの名前は、WebLogic Serverインスタンス名とブリッジ名で構成されます。mybridgeというブリッジがmyserverというWebLogic Serverインスタンスで実行されている場合、ブリッジ実行時MBeanの名前はmyserver.bridge.mybridgeとなります。

詳細は、次を参照してください:

メッセージング・ブリッジを異種混在クラスタや動的クラスタで使用できますか。

はい。ブリッジは任意のタイプのクラスタにターゲットとして指定できます。ターゲットとしてクラスタが指定されているブリッジのチューニングは、次のFAQエントリを参照してください。

ブリッジの分散ポリシーと移行ポリシーの推奨設定を教えてください。

ブリッジの分散ポリシーと移行ポリシーの設定は、ブリッジがクラスタにターゲット指定されていると有効になります。ブリッジでクラスタがターゲットとして指定されるのは、ブリッジのターゲットが直接クラスタに設定されているときです。

ターゲットとしてクラスタが指定されたブリッジにサーバーごとのインスタンスが必要な場合は、ブリッジの分散ポリシーと「移行ポリシー」をデフォルトである「分散完了」と「オフ」にそれぞれ設定することをお薦めします。

ターゲットとしてクラスタが指定されたブリッジにクラスタごとの単一インスタンスが必要な場合は、ブリッジの分散ポリシーと「移行ポリシー」を「シングルトン」と「失敗時」にそれぞれ設定することをお薦めします。「シングルトン」または「失敗時」が設定されたブリッジは、クラスタ・リーシングも構成されていないと起動しません。(ブリッジをターゲットとしてクラスタを指定できなくても、構成済のクラスタでシングルトン動作が必要な場合は、ブリッジのターゲットとして「移行可能ターゲット」を指定して、移行可能ターゲットの「移行ポリシー」を「必ず1回」に構成できます。)

ノート:

ブリッジの分散ポリシーと「移行ポリシー」を「分散完了」と「失敗時」に設定することや、「分散完了」と「常時」に設定することはお薦めしません。

ブリッジには独自の再試行論理が組み込まれているため、ブリッジに対する「再起動準備完了」設定は無視されます。