| Oracle® Fusion Middleware Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理 12c (12.2.1.3.0) E90315-01 |
|
 前 |
| Oracle® Fusion Middleware Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理 12c (12.2.1.3.0) E90315-01 |
|
|
前 |
この章の内容は次のとおりです。
メッセージング・ブリッジで、別個のWeblogic Serverドメイン間または異なるリリース間の2フェーズ・トランザクションやグローバル・トランザクションを処理できますか。
2フェーズ・トランザクションで「必ず1回」サービス品質を使用するようにメッセージング・ブリッジを構成しました。サービスの質を確保できないというエラーが発生するのはなぜですか。
「必ず1回」サービスがソースまたはターゲット・ブリッジ宛先で利用できない場合、メッセージング・ブリッジで自動的にサービス品質をダウングレードできますか。
メッセージング・ブリッジのソース宛先または対象宛先を構成する際に、「アダプタ・クラス・パス」フィールドを設定する必要はありますか。
ブリッジの分散ポリシーが「分散完了」として構成されている場合に、移行ポリシーを「常時」または「失敗時」に設定できますか。
ソース・ブリッジ宛先のパラメータの構成でエラーが発生したか、実際のソース宛先が動作しておらずメッセージング・ブリッジと通信できないかのいずれかと考えられます。
ブリッジのソース宛先が正しく構成されているかどうかを確認してください。コンソールの「JMSブリッジ宛先:構成」ページで以下のフィールドを確認します。
「接続URL」 - 接続ファクトリおよび実際の宛先のルックアップに使用するJNDIプロバイダのURL。
「宛先のJNDI名」 - ソース・ブリッジ宛先にマップされた実際の宛先のJNDI名。
「接続ファクトリのJNDI名」 - ソース・ブリッジ宛先にマップされた実際の宛先に対する接続を作成するために使用する接続ファクトリ。
「ユーザー名」/「パスワード」 - 実際のソース宛先にアクセスするためのパーミッションを持つユーザー。
ソース・ブリッジ宛先にマップされた実際のソース・キューまたはトピック宛先が正常に動作しているかどうかについて、次の点を確認します。
ソース宛先をホストするWebLogic Serverインスタンスは動作しているか。
ソース宛先をホストするJMSサーバーは正しくデプロイされているか。
注意:
ここではソース・ブリッジ宛先の接続障害を想定していますが、ターゲット・ブリッジ宛先の接続障害にもこの手順を適用できます。
通常、メッセージング・ブリッジはすべてのメッセージを転送します。一部のメッセージが転送されない場合は次の理由が考えられます。
一部のメッセージに有効期限がある場合、ソース宛先またはターゲット宛先のJMSプロバイダによりメッセージが失効します。
セレクタ・フィルタを指定するようにブリッジ・ソース宛先を構成した場合、フィルタ処理されたメッセージのみが転送されます。
ブリッジでは、転送の制限回数を超えた場合、メッセージをエラー宛先に自動で移動したり、自動で削除したりするオプションは直接提供されません。ただし、JMSプロバイダには、ブリッジ・ソース宛先でメッセージに関する同様の機能をもたらすオプションがあります。ブリッジ・ソース宛先をホストするJMSプロバイダで再配信制限オプションが有効な場合、ブリッジの自動再試行メカニズムがメッセージの再配信制限を超えないようにプロバイダを再構成することを検討してください。
はい - 「WebLogic Serverの別のリリースとの相互運用」を参照してください。
メッセージング・ブリッジでWebLogicドメイン間のトランザクションを処理するには、以下を追加で構成する必要があります。
サポートされているアダプタはWL_HOME\server\libディレクトリにあります。Exactly-once QOSについては、コンソールで「デプロイメント」>「コネクタ」ノードを選択して、トランザクション・アダプタjms-xa-adp.rarをブリッジが実行するドメインにデプロイする必要があります。
このjms-xa-adp.rarアダプタは、ソース・ブリッジ宛先およびターゲット・ブリッジ宛先の「JMSブリッジ宛先」>「構成」タブの「アダプタのJNDI名」属性でeis.jms.WLSConnectionFactoryJNDIXAとして識別される必要もあります。
WebLogic JMSの場合は、ソース・ブリッジ宛先およびターゲット・ブリッジ宛先の両方にマップされたキュー宛先またはトピック宛先で、トランザクションXAConnectionFactoryを使用していることを確認します。「JMS」→「接続ファクトリ」→「構成」→「トランザクション」コンソール・タブまたは構成ファイル(config.xml)で、次のエントリを確認します。
UserTransactionsEnabled=true XAConnectionFactory=true
サード・パーティJMSベンダーの場合は、ソース・ブリッジ宛先およびターゲット・ブリッジ宛先の両方にマップされた宛先で、トランザクション接続ファクトリを使用していることを確認します。
複数のリリース間で相互運用する場合の「必ず1回」のQOSの使用については、「WebLogic Serverの別のリリースとの相互運用」を参照してください。
はい、WebLogic Server管理コンソールの「メッセージング・ブリッジ」→「構成」→「全般」ページで「QOSデグラデーション」チェック・ボックスを選択すれば可能です。
ブリッジがソース・ブリッジ宛先およびターゲット・ブリッジ宛先と通信できるようにするには、それぞれの宛先を適切な.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"
メッセージング・ブリッジのデバッグを有効にすると、デバッグ・メッセージはデフォルトではサーバー・ログに送信されます。ただし、これらをWebLogic Server管理コンソールに表示する場合は、前述の文にDumpToConsoleを追加します。例:
-Dweblogic.debug.DebugMessagingBridgeStartupDumpToConsole=true
メッセージング・ブリッジの状態をモニターする際は、次の表5-1を参考にして対処方法を判断してください。詳細は、「メッセージング・ブリッジ・インスタンスの管理」を参照してください。
表5-1 メッセージング・ブリッジのモニター状態
| 説明 | アクション |
|---|---|
警告: ソース・アダプタが見つかりませんでした |
アダプタがデプロイされているか、またはソースJMSBridgeDestinationインスタンスのJNDI名が正しいかどうかを確認します。 |
警告: ターゲット・アダプタが見つかりませんでした |
アダプタがデプロイされているか、またはターゲットJMSBridgeDestinationインスタンスのJNDI名が正しいかどうかを確認します。 |
両方のアダプタが見つかりました - 接続を作成しています |
なし |
警告: 管理者によって停止されました |
なし |
警告: ソース・アダプタの検索に失敗しました |
アダプタがデプロイされているか、またはソースJMSBridgeDestinationインスタンスのJNDI名が正しいかどうかを確認します。 |
警告: ターゲット・アダプタの検索に失敗しました |
アダプタがデプロイされているか、またはターゲットJMSBridgeDestinationインスタンスのJNDI名が正しいかどうかを確認します。 |
2つのアダプタが見つかりました - 接続を作成します |
なし |
警告: ソースへの接続に失敗しました |
|
ソースに接続しました |
なし |
警告: ターゲットへの接続に失敗しました |
|
ターゲットに接続しました |
なし |
メッセージを転送しています |
なし |
警告: 接続に失敗しました - あとで再接続します |
ソース・ブリッジ宛先およびターゲット・ブリッジ宛先が正常に動作しているかどうかを確認します。 |
はい。メッセージング・ブリッジを使用して、分散宛先との間で送受信できます。以下の構成をお薦めします。
ソース宛先が分散宛先の場合、ブリッジは宛先に接続したときにいずれかの宛先メンバーに固定されます。ブリッジは、再接続するまでそのメンバーのみに接続し続けます。分散宛先の他のメンバーからのメッセージは受信しません。そのため、メンバーの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となります。
詳細は、次を参照してください:
Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発の概要とロードマップ
『WebLogic Scripting Toolの理解』のWebLogic Scripting Toolの使用方法に関する項
はい。ブリッジは任意のタイプのクラスタにターゲットとして指定できます。ターゲットとしてクラスタが指定されているブリッジのチューニングは、次のFAQエントリを参照してください。
ブリッジの分散ポリシーと移行ポリシーの設定は、ブリッジがクラスタにターゲット指定されていると有効になります。ブリッジは、そのターゲットがクラスタに直接指定されている場合、またはリソース・グループにスコープ指定され、そのリソース・グループがクラスタにターゲット指定されている場合にクラスタをターゲットとします。
ターゲットとしてクラスタが指定されたブリッジにサーバーごとのインスタンスが必要な場合は、ブリッジの分散ポリシーと「移行ポリシー」をデフォルトである「分散完了」と「オフ」にそれぞれ設定することをお薦めします。
ターゲットとしてクラスタが指定されたブリッジにクラスタごとの単一インスタンスが必要な場合は、ブリッジの分散ポリシーと「移行ポリシー」を「シングルトン」と「失敗時」にそれぞれ設定することをお薦めします。「シングルトン」または「失敗時」が設定されたブリッジは、クラスタ・リーシングも構成されていないと起動しません。(ブリッジをターゲットとしてクラスタを指定できなくても、構成済のクラスタでシングルトン動作が必要な場合は、ブリッジのターゲットとして「移行可能ターゲット」を指定して、移行可能ターゲットの「移行ポリシー」を「必ず1回」に構成できます。)
注意:
ブリッジの分散ポリシーと「移行ポリシー」を「分散完了」と「失敗時」に設定することや、「分散完了」と「常時」に設定することはお薦めしません。ブリッジには独自の再試行論理が組み込まれているため、ブリッジに対する「再起動準備完了」設定は無視されます。
