| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 12cリリース1 (12.1.1) B65900-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 12cリリース1 (12.1.1) B65900-02 |
|
前 |
次 |
この章では、クラスタ環境での分散宛先などの拡張WebLogic JMSリソースを構成する方法について説明します。
WebLogic Serverのクラスタとはドメイン内で連携して動作するサーバーのグループであり、単一のサーバーよりもスケーラブルで信頼性のあるアプリケーション・プラットフォームを提供します。クラスタはそのクライアントからは単一のサーバーに見えますが、実際には一体で機能するサーバー群です。
|
注意: JMSクライアントがクラスタに正常にアクセスするには、一意のWebLogic Server名が必要です(WebLogic Serverが別々のドメインに存在する場合にも必要です)。このため、JMSクライアントがアクセスするすべてのWebLogic Serverの名前は一意でなければなりません。 |
JMSクラスタリングには、以下のメリットがあります。
クラスタ内の複数のサーバーにわたる宛先のロード・バランシング
管理者は、複数のJMSサーバーを構成し、それらを定義済みのWebLogic Serverに割り当てることで、クラスタ内の複数のサーバーにわたる宛先のロード・バランシングを確立できます。各JMSサーバーは、厳密に1つのWebLogic Serverインスタンスにデプロイされ、宛先の集合に対するリクエストを処理します。
|
注意: ロード・バランシングは動的ではありません。構成の段階で、システム管理者がJMSサーバーのターゲットを指定してロード・バランシングを定義します。 |
宛先の高可用性
分散宛先 - 分散宛先のキューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic JMSは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。分散宛先の詳細については、「分散宛先リソースの構成」を参照してください。
ストア・アンド・フォワード - JMSモジュールは、SAFサービスを利用して、ローカルのJMSメッセージ・プロデューサがリモートのキューまたはトピックに確実にメッセージを送信できるようにします。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存されて、リモートの宛先が使用可能になった時点で転送されます。詳細は、『Oracle WebLogic Serverストア・アンド・フォワードの構成と管理』のストア・アンド・フォワード・サービスに関する項を参照してください。
自動フェイルオーバーの場合、WebLogic Serverはサーバー・レベル(サーバー・インスタンス)での移行をサポートします。WebLogic Serverがホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細は、『Oracle WebLogic Serverクラスタの使用』のサーバー全体の移行に関する項を参照してください。
クラスタ内のあらゆるサーバーからの、宛先へのクラスタ全体で透過的なアクセス
管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーから宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverインスタンスにデプロイできます。接続ファクトリについては、「接続ファクトリの構成」を参照してください。
スケーラビリティ
前述した、クラスタ内の複数のサーバーにわたる宛先のロード・バランシング。
接続ファクトリを通じた、複数のJMSサーバーでのアプリケーション負荷の分散。その結果として、個々のJMSサーバーでの負荷が削減され、かつ接続先を特定のサーバーに決めることでセッションの集中が可能となります。
マルチキャストのサポート(オプション)。JMSサーバーで配信しなければならないメッセージの数が削減されます。JMSサーバーでは、サブスクライブしているアプリケーションの数に関係なく、マルチキャストIPアドレスと関連付けられている各ホスト・グループに対してメッセージが1コピーだけ転送されます。
移行性
WebLogic Serverはサーバー・レベル(サーバー・インスタンス)での移行をサポートします。WebLogic Serverがホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細は、『Oracle WebLogic Serverクラスタの使用』のサーバー全体の移行に関する項を参照してください。
また、「必ず1回」のサービスとして、WebLogic JMSはクラスタリングされた環境のためにWebLogic Serverに実装されている移行フレームワークを活用します。これにより、WebLogic JMSは、移行リクエストに適切に応答し、JMSサーバーを正しい順序でオンラインまたはオフラインにすることができます。移行には、予定されている手動移行のほかに、クラスタ内のWebLogic Serverの障害に対応して行われる自動移行があります。詳細については、「JMS関連サービスの移行」を参照してください。
JMSクライアントに対するサーバー・アフィニティ
クラスタ用に構成したロード・バランシング・アルゴリズム(ラウンドロビン・アフィニティ、重みベース・アフィニティ、またはランダム・アフィニティ)は、JMSクライアント接続のためのサーバー・アフィニティを提供します。JMSアプリケーションから指定したサーバー・インスタンスに接続できる場合、JMSは同じサーバー・インスタンスとの新しいJMS接続を確立しようとします。サーバー・アフィニティの詳細は、『Oracle WebLogic Serverクラスタの使用』のクラスタでのロード・バランシングに関する項を参照してください。
WebLogicクラスタを使用した場合の機能と利点の詳細は、『Oracle WebLogic Serverクラスタの使用』のWebLogic Serverのクラスタリングに関する項を参照してください。
管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverにデプロイできます。接続ファクトリの構成とデプロイメントの詳細は、「接続ファクトリの構成パラメータ」を参照してください。
アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。宛先へのリクエストが送信されるWebLogic Serverインスタンスが、接続ファクトリのホストであって、JMSサーバーまたは宛先のホストではない場合、リクエストは接続ファクトリによって、JMSサーバーと宛先のホストになっている適切なWebLogic Serverインスタンスに転送されます。
管理者は、クラスタ内の様々なサーバー上の複数のJMSサーバーに一意の名前が付けられているかぎり、それらのJMSサーバーを構成して、JMSキューまたはトピック・リソースを割り当てることができます。アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。JMSサーバーで処理されない宛先へのリクエストは、適切なWebLogic Serverインスタンスに転送されます。JMSサーバーの構成とデプロイメントの詳細は、「JMSサーバーの構成」を参照してください。
単一のWebLogicドメイン環境または複数ドメイン環境でJMSオブジェクトおよびリソース(JMSサーバー、JMSモジュール、JMSリソースなど)がクラスタリング環境で動作するように構成する際には、いくつかのネーミング要件があります。詳細については、「JMS構成のネーミング要件」を参照してください。
分散宛先リソースは、単一の論理宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは個々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic Serverは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。詳細については、「分散宛先リソースの構成」を参照してください。
JMSサービスは、サーバー全体の移行(サーバーでホストされるすべてのサービスを別のマシンに移行する場合)だけでなく、シングルトン・サービスの移行フレームワークに組み込むこともできます。したがって、たとえばサーバーの障害に対処する場合や定期的な保守を実施する場合に、JMSサーバーとそのすべての宛先をクラスタ内の別のWebLogic Serverに移行することも可能です。これには、予定されている手動移行のほかに自動移行も含まれます。JMSサービスの移行の詳細は、「JMS関連サービスの移行」を参照してください。
クラスタ環境でWebLogic JMSを使用する場合は、以下のガイドラインに従います。
クラスタ化環境を構成します。『Oracle WebLogic Serverクラスタの使用』のWebLogicクラスタの設定に関する項を参照してください。
管理コンソールを使用して、ユーザー定義のJMS接続ファクトリのターゲット・サーバーを指定します。接続ファクトリでは、単一のサーバーまたはクラスタをターゲットとして指定できます。ターゲットとは、クラスタリングをサポートするために接続ファクトリに関連付けられたサーバーのインスタンスです。
接続ファクトリの構成属性の詳細は、「接続ファクトリの構成」を参照してください。
必要に応じて、管理コンソールを使用してJMSサービス用の移行可能なサーバーを指定します。たとえば、JMSサーバーであれば、単一のサーバーまたは移行可能なサーバーをターゲットとして指定できます。移行可能なターゲットとは、クラスタ内にあるサーバー・インスタンスのセットで、クラスタ内で1台のサーバーに障害が発生した場合に、JMSのような「必ず1回」のサービスをホストできるものです。
移行可能なJMSサーバー・ターゲットの詳細は、「JMS関連サービスの移行」を参照してください。JMSサーバーの構成属性の詳細は、「JMSサーバーの構成」を参照してください。
|
注意: 同じ宛先を複数のJMSサーバーにデプロイすることはできません。また、1つのJMSサーバーを複数のWebLogic Serverにデプロイすることもできません。 |
必要に応じて、クラスタ内に物理JMS宛先を仮想的な分散宛先セットの一部として構成できます。詳細については、「クラスタ内での分散宛先」を参照してください。
サーバーまたはネットワークの障害が発生した場合、JMSメッセージ・プロデューサおよびコンシューマ・オブジェクトは(使用可能なものがあれば)別のサーバー・インスタンスに透過的にフェイルオーバーを試みます。WebLogic Serverリリース9.1以降では、既存のクライアント・コードを手動で構成または変更しなくても、WebLogic JMSメッセージ・プロデューサは、使用可能なサーバー・インスタンスへ自動的に再接続しようとします。WebLogic Serverリリース9.2では、管理コンソールまたはWebLogic JMS APIを利用して、使用可能なサーバー・インスタンスに自動的に再接続を試行するようにWebLogic JMSメッセージ・コンシューマを構成できます。『Oracle WebLogic Serverアプリケーションの開発』のJMSクライアントの自動フェイルオーバーに関する項を参照してください。
|
注意: WebLogic Server 9.x以前のJMSクライアント・アプリケーションについては、『Oracle WebLogic Server JMSのプログラミング』のWebLogic Server 9.x以前のリリースでの障害に関するプログラミングの考慮事項に関する項を参照してください。 |
さらに、サービスの自動移行機能を実装すると、JMSのような「必ず1回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しなくなります。「JMS関連サービスの移行」を参照してください。WebLogic Serverでは、サーバー・レベル、つまり、サーバー・インスタンス全体のデータ移行もサポートされています。また、サーバー・インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。『Oracle WebLogic Serverクラスタの使用』のサーバー全体の移行に関する項を参照してください。
クラスタ化環境では、WebLogic Serverは分散宛先を構成することによって1つのサーバーで障害が発生した場合でもサービスを継続できます。分散宛先では、キューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。「クラスタ内での分散宛先」を参照してください。
また、高可用性クラスタリング・ソフトウェアを実装することをお薦めします。これにより、WebLogic Serverベースのアプリケーションに、統合された使いやすいソリューションがもたらされます。
JMS関連サービスはシングルトン・サービスであるため、クラスタ内のすべてのサーバー・インスタンスでアクティブになるわけではありません。かわりに、それらはデータの一貫性を保持するためクラスタ内の単一サーバーに固定されます。シングルトンJMSサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、JMSサービスを移行可能ターゲット・リスト内の任意のサーバー・インスタンスに自動で移行できるようにWebLogic Serverを構成できます。ホスト・サーバーに障害が発生した場合は、移行可能なJMSサービスも手動で移行できます。また、定期的なサーバー・メンテナンスを実施する前に、JMSサービスを手動で移行することも可能です。
移行可能なJMS関連サービスには以下が含まれます:
JMSサーバー - ターゲット指定されているJMSモジュール内のキューおよびトピックの管理コンテナです。「JMSサーバーの構成」を参照してください。
ストア・アンド・フォワード(SAF)サービス - メッセージが送信された時点でリモート・エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア・アンド・フォワードするサービスです。移行できるのは、JMS SAF(送信機能のみ)用に構成された送信SAFエージェントのみです。『Oracle WebLogic Serverストア・アンド・フォワードの構成と管理』のストア・アンド・フォワード・サービスに関する項を参照してください。
パス・サービス - JMSメッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ・リソースへのマッピングの保持に使用できる永続マップです。パス・サービスは、クラスタごとに1つずつ構成します。「WebLogicパス・サービスの使用」を参照してください。
カスタム永続ストア - ユーザーが定義するディスク・ベースのファイル・ストアまたはJDBC対応データベースです。JMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するために使用します。『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項を参照してください。
移行可能ターゲットを使用すると、高可用性のためのJMS関連サービスを構成できます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。つまり、移行可能ターゲットを使用することで、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべてのサービスが移行されます。
『Oracle WebLogic Serverクラスタの使用』のサービスの移行フレームワークに関する項を参照してください。
管理者は、ヘルス監視サブシステムを活用することで、障害が発生した現在のホスト・サーバーでホストされているJMSサービスが正常に動作しているサーバーに自動的に移行するよう、移行可能ターゲットを構成できます。JMS関連サービスの自動移行の構成については、『Oracle WebLogic Serverクラスタの使用』のJMS関連サービスの自動移行を構成する手順に関する項を参照してください。
ホスト・サーバーで障害が発生した場合や、サーバー・メンテナンスを実施する前には、JMS関連サービスを正常なサーバーに手動で移行できます。JMS関連サービスの手動移行の構成については、『Oracle WebLogic Serverクラスタの使用』のJMS関連サービスの手動移行を構成する手順に関する項を参照してください。
「フェイルオーバーの場合」で説明したように、カスタム永続ストアを含むJMSサービスは、「サーバー全体」の移行機能の一部として移行したり、移行可能なJMS関連サービスをターゲットとした「サービス・レベル」の移行の一部として移行したりできます。移行可能なJMS関連サービスで、デフォルトの永続ファイル・ストアを使用することはできないので、カスタム・ファイル・ストアまたはJDBCストアを構成し、そのストアと関連付けられたJMSサーバーまたはSAFエージェントと同じ移行可能ターゲットにそのストアをターゲット指定する必要があります。(パス・サービスの場合は、専用のカスタム・ストアと移行可能ターゲットを使用するのがベスト・プラクティスです。)
移行可能なカスタム・ファイル・ストアは、クラスタ内の移行可能ターゲット・サーバーから使用できる共有ディスクに構成したり、移行前/移行後スクリプトを使用してバックアップ・サーバー・ターゲットに移行したりできます。永続ストアの移行の詳細は、『Oracle WebLogic Serverクラスタの使用』のJMSサービスで使用できるカスタム・ストアに関する項を参照してください。
WebLogic Serverパス・サービスは、JMSメッセージ順序単位内のメッセージのグループから、クラスタ内のメッセージ・リソースへの、マッピングの保持に使用できる永続マップです。サーブレットをホストするクラスタのメンバー、分散キュー・メンバー、またはストア・アンド・フォワード・エージェントにメッセージを固定することによって、順序付けを実現できます。パス・サービスは、クラスタごとに1つずつ構成します。メッセージ順序単位機能の詳細は、『Oracle WebLogic Server JMSのプログラミング』のメッセージ順序単位の使用に関する項を参照してください。
クラスタにパス・サービスを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのパス・サービスの構成に関する項を参照してください。
クラスタのパス・サービスは、高可用性の確保を目的として、自動または手動によるサービス移行用の移行可能ターゲットにターゲット指定できます。ただし、移行可能なパス・サービスではデフォルト・ストアを使用できないため、カスタム・ストアを構成し、同じ移行可能ターゲットにターゲット指定する必要があります。さらに、ベスト・プラクティスとしては、その移行可能ターゲットのユーザーを、パス・サービスとそのカスタム・ストアに限定する必要があります。『Oracle WebLogic Serverクラスタの使用』のサービスの移行フレームワークに関する項を参照してください。
メッセージ順序単位とパス・サービス・ベースのルーティングを実装する際には、以下のことに留意してください。
各パス・サービス・マッピングは永続ストアに格納されます。パス・サービスを構成する場合、高可用性ソリューションを使用する永続ストアを選択します。「永続ストアの高可用性」を参照してください。
複数のプロデューサが同じ順序単位名を使用してメッセージを送信する場合、すべてのメッセージは同じパス・エントリを共有し、同じメンバー・キュー宛先を持ちます。
順序単位名に必要なルートにアクセスできない場合、メッセージを送信したプロデューサはJMSOrderExceptionをスローします。この例外がスローされるのは、JMSメッセージ・システムが必要なサービス品質を満たすことができないからです。特定の順序単位に対しては、1つの分散宛先メンバーだけがメッセージを消費できます。
パス・エントリは、最後のプロデューサと最後のメッセージ参照が削除されたときに自動的に削除されます。
システムによっては、パス・サービスを使用すると、パス・エントリを作成、読み取り、および削除するためのリモート・ディスク処理のため、システムのスループットが低下する場合があります。
分散キューとその個々のメンバーは、一意の宛先を表します。例:
DXQ1は、Q1とQ2というメンバーを持つ分散キューです。またDXQ1はFredという名前の順序単位を持ち、パス・サービスによってQ2メンバーにマップされています。
メッセージM1がDXQ1に送信されると、パス・サービスによってQ2へのルートが定義されます。
メッセージM1が直接Q2に送信される場合、パス・サービスによるルーティングは行われません。これは、アプリケーションが直接Q2を選択し、分散宛先からメンバーを選択するよう要求されなかったからです。
パス・サービスを使用する場合、メッセージを分散宛先に送信します。使用しない場合は、直接メンバーに送信します。
ある分散キューの中に、同じ順序単位名の宛先が複数存在してもかまわません。例:
Fredという順序単位名のキューQ3が存在するとします。Q3がDXQ1に追加された場合、分散キューの中に同じ順序単位名の宛先が2つ存在することになります。Q3とDXQ1は同じ順序単位名Fredを共有しますが、それぞれが一意のルートと宛先を持っており、これによりサーバーは宛先ごとに適切なメッセージ順序付けを提供し続けることができます。
分散キューからキューを削除する前、または分散キューにキューを追加する前に、キューを空にします。削除されたメンバーのパス・エントリはパス・サービスによって削除されますが、短い遷移期間が発生します。このため、キューが削除されたにもかかわらずパス・エントリがまだ存在する場合、生成されたメッセージによってJMSOrderExceptionがスローされる場合があります。
WebLogic JMSでは、サード・パーティJMSプロバイダをローカルWebLogic Server JNDIツリー内で参照できます。JMSモジュール内で外部サーバー・リソースを使用することで、外部のJMSプロバイダを即座にマップして、関連付けられた接続ファクトリと宛先をローカルJMSオブジェクトのようにWebLogic JNDIツリーに表示できます。また、別のクラスタまたはドメインにあるWebLogic Serverのリモート・インスタンスをローカルWebLogic JNDIツリー内で参照することもできます。
リモートおよび外部JMSプロバイダの統合の詳細は、『Oracle WebLogic Server JMSのプログラミング』のWebLogic JMSをEJBやサーブレットと組み合せて使用するために拡張された2EEサポートに関する項を参照してください。
以下の節では、外部サーバーの機能と、リモートMQSeries JNDIプロバイダにアクセスするためのサンプル構成について説明します。
外部JMSサーバーがデプロイされると、WebLogic Server JNDIにローカルの接続ファクトリと宛先のオブジェクトが作成されます。外部接続ファクトリまたは宛先のオブジェクトがローカル・サーバーでルックアップされると、そのオブジェクトはリモートJNDIディレクトリで実際のルックアップを実行し、そのディレクトリから外部オブジェクトが返されます。
この方法を使用すると、複数のWebLogicメッセージング・ブリッジ宛先の構成が簡単になります。外部サーバーが、JNDI初期コンテキスト・ファクトリおよび接続URLの構成の詳細をメッセージング・ブリッジ宛先の構成の外側に移すからです。外部接続ファクトリおよび宛先JNDI名をオブジェクトごとに指定するだけで済みます。
メッセージング・ブリッジの構成の詳細は、『Oracle WebLogic Serverメッセージング・ブリッジの構成と管理』を参照してください。
また、この構成の簡素化は、WebLogic JMSでのWebLogicサーブレット、EJB、およびメッセージドリブンBean (MDB)の構成にも当てはまります。たとえば、MDBのweblogic-ejb-jar.xmlファイルではローカルJNDI名を指定でき、外部JMSサーバーを使用してMDBがメッセージを受け取る場所を制御できます。具体的には、あるJMS宛先およびサーバーと通信するためにある環境でMDBをデプロイし、同じweblogic-ejb-jar.xmlファイルを別のサーバーにデプロイして、それを別のJMS宛先と通信させることができます。その際、weblogic-ejb-jar.xmlファイルを復元して編集する必要はありません。
外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。これにより、1つのJNDIディレクトリに対して複数の外部接続ファクトリと宛先のオブジェクトを定義できます。
WebLogic Server管理コンソールを使用すると、システム・モジュール内の外部サーバー・リソースを構成、変更、ターゲット指定、および削除できます。外部サーバー・タスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。
|
注意: エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、第5章「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。 |
一部の外部サーバー・オプションは、動的に構成できます。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての外部サーバー・オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスの「ForeignServerBean」を参照してください。
外部サーバーを定義したら、接続ファクトリおよび宛先のオブジェクトを構成できます。各外部サーバーに対して、1つまたは複数の接続ファクトリおよび宛先(キューまたはトピック)を構成できます。
JMSモジュール内の外部接続ファクトリ・リソースには、リモートJNDIプロバイダの接続ファクトリのJNDI名、ローカルWebLogic Server JNDIツリー内でその接続ファクトリにマップされるJNDI名、およびユーザー名とパスワード(オプション)が定義されます。
外部接続ファクトリは、親の外部サーバーの割当て先となる各WebLogic Serverインスタンスに対してレプリケートされていないJNDIオブジェクトを作成します(クラスタ内の各ノードにJNDIオブジェクトを作成するには、クラスタに外部サーバーを割り当てます)。
JMSモジュール内の「外部宛先です」リソースは、キューまたはトピックを表します。外部宛先には、外部JNDIプロバイダでルックアップされる宛先のJNDI名、およびローカルWebLogic Serverで宛先がマップされるJNDI名が保持されます。外部宛先がローカル・サーバーでルックアップされる場合、ルックアップはリモートJNDIディレクトリで実行され、そのディレクトリから宛先オブジェクトが返されます。
次の表に、リモートMQSeries JNDIプロバイダにアクセスする場合のサンプル構成を示します。
表4-1 MQSeriesサンプル構成
| 外部JMSオブジェクト | オプション名 | サンプル構成データ |
|---|---|---|
|
外部サーバー |
名前 JNDI初期コンテキスト・ファクトリ JNDI接続URL JNDIプロパティ |
MQJNDI com.sun.jndi.fscontext.RefFSContextFactory ファイル:/MQJNDI/ (必要な場合、カンマ区切りのname=valueプロパティ・リストを入力します)。 |
|
外部 接続ファクトリ |
名前 ローカルJNDI名 リモートJNDI名 ユーザー名 パスワード |
MQ_QCF mqseries.QCF QCF weblogic_jms weblogic_jms |
|
外部 宛先1 外部 宛先2 |
名前 ローカルJNDI名 リモートJNDI名 名前 ローカルJNDI名 リモートJNDI名 |
MQ_QUEUE1 mqseries.QUEUE1 QUEUE_1 MQ_QUEUE2 mqseries.QUEUE2 QUEUE_2 |
JMSモジュール内の分散宛先リソースは、単一の論理宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、スタンドアロンの宛先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMSに、クラスタ内の分散宛先メンバーのためのロード・バランシングおよびフェイルオーバー機能があるためです。
以降の節では、分散宛先の作成、モニター、およびロード・バランシングを行う方法について説明します。
|
注意: 重み設定された分散宛先はWebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。 |
WebLogic Server 9.x以降には、共通分散宛先と重み設定された分散宛先という2種類の分散宛先が用意されています。WebLogic Server 9.xより前のリリースでは、WebLogic管理者が、物理宛先を分散宛先のメンバーとして機能するように手動で頻繁に構成する必要がありました。この方法は、追加のメッセージ負荷または容量に対応するメンバーを作成できるという柔軟性を備えていました。しかし、このような重み設定された分散宛先はクラスタ内で一貫してデプロイされなかったため、管理上およびアプリケーション上の問題が発生することもよくありました。このタイプの分散宛先は、公式には「重み設定された分散宛先」(WDD)と呼ばれます。
共通分散宛先(UDD)は、分散宛先アプリケーションの管理と開発を大幅に簡略化します。共通分散宛先を使用すると、宛先のメンバーを作成したり指定したりする必要がなくなります。代わりに、WebLogic Serverによって、JMSモジュールが割り当てられるJMSサーバー上に必要なメンバーが均等に作成されます。この機能によって、すべての分散宛先のパラメータ(重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ)を一貫して構成できます。
分散宛先メンバーを手動で調整する場合は、従来の重み設定された分散宛先の機能も依然として使用できます。ただし、クラスタ内で一貫してデプロイされていない重み設定された分散宛先に起因して起こり得る管理上およびアプリケーションの問題を回避するため、共通分散宛先を構成することをお薦めします。
アプリケーションでの分散宛先の使用の詳細は、『Oracle WebLogic Server JMSのプログラミング』の分散宛先の使用に関する項を参照してください。
WebLogic Server管理コンソールを使用すると、次のJMSシステム・モジュールのUDDリソースを構成、変更、ターゲット指定および削除できます。
|
注意: エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、第5章「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。 |
共通分散宛先の使用のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
共通分散宛先オプションの中には、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての共通分散宛先オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。
次の項では、共通分散宛先の追加情報を説明します。
ドメイン内の特定のJMSサーバーのみにターゲット指定できる、モジュール内のスタンドアロンのキューおよびトピック・リソースとは異なり、UDDは1つまたは複数のJMSサーバー、1つまたは複数のWebLogic Serverインスタンス、または1つのクラスタのターゲットとして指定できます。UDDの目的は、そのメンバーをドメイン内の各JMSサーバーに分散することだからです。たとえば、UDDをクラスタのターゲットとして指定した場合、そのクラスタ内の各JMSサーバーでメンバーが均等に構成されます。
|
注意: UDDのターゲットを変更すると、メンバー宛先が削除され、メッセージが失われてしまうおそれがあります。 |
また、UDDを構成するときにサブデプロイメント・グループを使用して、特定のリソースを分散メンバーにリンクできます。たとえば、jmssysmod-jms.xmlというシステム・モジュールが、構成済みのJMSサーバーを持つwlserver1、wlserver2、wlserver3という3つのWebLogic Serverインスタンスのターゲットとして指定されている場合に、1つの共通分散キューと接続ファクトリを各サーバー・インスタンスのターゲットとして指定するのであれば、共通分散キューと接続ファクトリをservergroupという名前の1つのサブデプロイメント内でグループ化して、これらのリソースが常にこれらのサーバー・インスタンスにリンクされるようにすることができます。
次に、サブデプロイメント・リソースservergroupをjmssysmod-jms.xmlでどのように指定するのかを示します。
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
<connection-factory name="connfactory">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.connectionfactory.CF</jndi-name>
</connection-factory>
<uniform-distributed-queue name="UniformDistributedQueue">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.queue.UDQ</jndi-name>
<forward-delay>10</forward-delay>
</uniform-distributed-queue>
</weblogic-jms>
次に、ドメインの構成ファイルでサブデプロイメントservergroupをどのようにターゲット指定するかを示します。
<jms-system-resource>
<name>jmssysmod-jms</name>
<target>cluster1,</target>
<sub-deployment>
<name>servergroup</name>
<target>wlserver1,wlserver2,wlserver3</target>
</sub-deployment>
<descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
</jms-system-resource>
共通分散宛先でのメッセージの生成、挿入、および消費処理は、プログラム的に(JMXと実行時MBean APIを使用)、または管理的に(管理コンソールを使用)休止または再開できます。外部リソースに障害が発生したとき、JMSサブシステムがメッセージの受け付けと配信(および再配信)を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止(および再開)することで、外部リソースの障害発生時のJMSサブシステムの動作を制御できます。
「休止と再開」の機能の詳細は、「宛先でのメッセージ処理の制御」を参照してください。
共通分散宛先メンバーの実行時統計は、管理コンソールを使用してモニターできます。「JMS統計のモニター」を参照してください。
共通分散トピック・メッセージのForwarding Policyは、送信済メッセージがすべてのメンバーに転送されるかどうかを指定します。
有効な値は以下のとおりです。
Replicated: デフォルトです。すべての物理トピック・メンバーは各送信済メッセージを受信します。メッセージが物理トピック・メンバーのいずれかに着信する場合、該当する共通分散トピックの他のメンバーにこのメッセージのコピーが転送されます。いずれかの特定のメンバー上のサブスクリプションは、共通分散トピックの論理名または特定の共通分散トピック・メンバーに送信されたメッセージのコピーを取得します。
Partitioned: メッセージ受信側の物理メンバーは、メッセージを認識する共通分散トピックの唯一のメンバーです。メッセージがパーティション化された共通分散トピックの論理名にパブリッシュされるとき、特定の1つの物理トピック・メンバー上にのみ着信します。メッセージが物理トピック・メンバー上に着信すると、メッセージは共通分散宛先の残りのメンバーには転送されず、他の物理トピック・メンバー上のサブスクライバは当該メッセージのコピーを取得しません。
大半の新しいアプリケーションでは、次のように構成される共通分散トピック上の論理サブスクリプション・トポロジと組み合せて、Partitioned転送ポリシーを使用します。
各物理メンバー上で直接作成された同一名の物理サブスクリプション。
UnrestrictedのクライアントIDポリシー。
Sharableのサブスクリプション共有ポリシー。
パーティション化された分散トピックの作成および使用の詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・ヘルプのシステム・モジュールにおけるパーティション化された共通分散トピックの作成に関する項。
『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』の分散トピックを使用したMDBの構成およびデプロイに関する項
『Oracle WebLogic Server JMSのプログラミング』の拡張パブリッシュ/サブスクライブ・アプリケーションの開発に関する項
パーティション化されたトピックのパブリッシャには、接続ファクトリのAffinityおよびLoad Balance属性をチューニングすることによって、複数のメンバー全体に渡るメッセージのロード・バランシング・オプションがあります。「順序単位」メッセージは、UOOルーティング・ポリシーおよびサブスクライバ・ステータスに基づいて適切なメンバーにルーティングされます。Oracle WebLogic Server管理コンソール・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項を参照してください。
|
注意: 重み設定された分散宛先はWebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。 |
WebLogic Server管理コンソールを使用すると、JMSシステム・モジュール内のWDDリソースを構成、変更、ターゲット指定、および削除できます。分散トピックまたはキューを構成する場合、「メンバーの均等割当て」チェック・ボックスのチェックをはずすことによって、既存のキューとトピックを手動で選択して分散宛先に追加し、分散宛先メンバーの重みを調整できます。
重み設定された分散宛先のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
重み設定された分散宛先オプションの中には、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての重み設定された分散宛先オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。
UDDとは異なり、WDDメンバーは管理コンソールまたは実行時MBeanでモニターできません。また、WDDメンバーはドメイン内のJMSサーバーまたはWebLogic Serverインスタンスに均等に割り当てることはできません。かわりに、これらのインスタンス上で新しいWDDメンバーを手動で構成し、手動でWDDに追加する必要があります。
JMSは分散宛先を使用して、複数の宛先にメッセージの負荷を分散し、バランスを取ることができます。これによって、リソースがさらに効率的に利用され、レスポンス時間が改善されます。JMSのロード・バランシング・アルゴリズムでは、メッセージの送信先となる物理宛先に加えて、コンシューマの割当て先の物理宛先も決定されます。
WebLogic JMSは、任意の分散宛先セットに含まれている複数の物理宛先間でメッセージのロード・バランシングを行うための2種類のアルゴリズムをサポートしています。これらのロード・バランシング・オプションのどちらかを選択するには、管理コンソールで分散トピックまたは分散キューを構成します。
ラウンドロビン・アルゴリズムでは、WebLogic JMSは分散宛先内の物理宛先の序列を管理します。メッセージの負荷は、WebLogic Server構成(config.xml)ファイルに定義されている順番で、一度に1つずつ物理宛先に分散されます。各WebLogic Serverは、同一の序列を維持しますが、その序列内の位置は異なります。特定の分散宛先を使用して単一のサーバー内で複数のスレッドを実行すると、スレッドからメッセージが生成されるたびに、メンバーが割り当てられている物理宛先に関連して、これらのスレッドが互いに影響し合うことになります。ラウンドロビンはデフォルトのアルゴリズムで、構成の必要はありません。
重み設定された分散宛先のみの場合、セット内の物理宛先のいずれかに重みが割り当てられている場合、それらの物理宛先は序列内に複数回発生します。
ランダム分散アルゴリズムでは、物理宛先に割り当てられている重みを使用して、一連の物理宛先の重み付き宛先を計算します。メッセージの負荷は、疑似ランダム的に宛先にアクセスすることで、物理宛先に分散されます。短期的には、負荷は重みには直接比例しません。長期的には、極限に近い分散が行われます。純粋なランダム分散は、重みすべてに同じ値を設定することで達成できます。この値は通常1です。
メンバーが追加または削除された(管理者が行うか、WebLogic Serverがシャットダウンまたは再起動した結果発生したもの)場合は、分散を再計算する必要があります。ただし、このようなイベントは頻繁に発生せず、計算は通常単純で、O(n)時間で実行されます。
アプリケーションがコンシューマを作成するときは、宛先を指定する必要があります。その宛先が分散宛先を表す場合、WebLogic JMSではコンシューマのメッセージ受信元となる物理宛先を見つける必要があります。使用する宛先メンバーの選択には、ロード・バランシング・アルゴリズム(「ロード・バランシング・オプション」を参照)のいずれかが使用されます。この選択は、コンシューマの作成時に1回だけ行われます。その後、コンシューマはそのメンバーのみからメッセージを受信するようになります。
プロデューサがメッセージを送信するとき、WebLogic JMSはメッセージが送信される宛先を確認します。宛先が分散宛先である場合は、メッセージの送信先がWebLogic JMSによって決定されます。つまり、プロデューサは「ロード・バランシング・オプション」で説明されているロード・バランシング・アルゴリズムのいずれかに従って、宛先のメンバーのいずれかに送信します。
プロデューサはメッセージを送信するたびにこのような決定を行います。ただし、コンシューマとプロデューサ間の序列の保証が脅かされることはありません。コンシューマのロード・バランシングがいったん行われると、コンシューマは単一の宛先メンバーに固定されるためです。
|
注意: プロデューサが永続メッセージを分散宛先に送信しようとする場合、永続ストアを利用している分散メンバーにまずメッセージが転送されるよう、あらゆる努力がなされます。ただし、分散メンバーがいずれも永続ストアを利用していない場合でも、メッセージは選択されているロード・バランシング・アルゴリズムに従って、メンバーのいずれかに送信されます。 |
「ロード・バランシング・オプション」に説明されているアルゴリズムに加えて、WebLogic JMSでは宛先のインスタンスを選択するときに次のヒューリスティックが使用されます。
トランザクション・セッション内で複数のメッセージを作成するときは、作成されたメッセージすべてを同じWebLogic Serverに送信しようとします。つまり、セッションが単一の分散宛先に複数のメッセージを送信した場合は、すべてのメッセージが同じ物理宛先に転送されます。セッションによって複数のメッセージが複数の異なる分散宛先に送信された場合は、同じWebLogic Serverがサービスを提供する一連の物理宛先が選択されるようになります。
接続ファクトリの「サーバー・アフィニティの有効化」パラメータでは、分散宛先内にある複数のメンバー宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverが、同じWebLogic Server上で実行されている他のローカル宛先メンバーの間でロード・バランシングを最初に試みるかどうかを定義します。
|
注意: 「サーバー・アフィニティの有効化」属性は、キュー・ブラウザには影響しません。したがって、「サーバー・アフィニティの有効化」が有効になっている場合でも、分散キューに作成されたキュー・ブラウザをリモート分散キュー・メンバーに固定できます。 |
接続ファクトリでサーバー・アフィニティを無効化するには:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項の説明に従って、「JMS接続ファクトリ」→「構成」→「全般」ページに移動します。
「サーバー・アフィニティの有効化」フィールドを次のように定義します。
「サーバー・アフィニティの有効化」チェック・ボックスを選択します(trueとします)。この場合、分散宛先セット内にある複数の物理宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverは、同じWebLogic Server上で実行されている他の物理宛先の間でロード・バランシングを最初に試みます。
「サーバー・アフィニティの有効化」チェック・ボックスを選択しない場合(False)、WebLogic Serverは、分散宛先セット内の複数の物理宛先にまたがるコンシューマまたはプロデューサのロード・バランシングを実行し、同じWebLogic Serverで実行されている他の物理宛先を無視します。
「保存」をクリックします。
「サーバー・アフィニティの有効化」の設定が分散宛先のメンバー間のロード・バランシングにどのように影響するかについては、「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響」を参照してください。
複数のリモートの物理的キュー間でコンシューマのロード・バランシングを行う場合、1つまたは複数のキューにコンシューマがないとき、それらのキューだけがロード・バランシングの対象となります。セット内の物理的キューすべてに少なくとも1つのコンシューマが含まれるようになると、標準のアルゴリズムが適用されます。
また、プロデューサがメッセージを送信するとき、コンシューマのないキューはメッセージ生成の対象にはなりません。ただし、任意のキューのインスタンスのいずれにもコンシューマが含まれていない場合を除きます。
分散宛先でメッセージの生成または挿入が休止された場合、それらはメッセージ生成の対象とは見なされません。同様に、分散宛先でメッセージの消費が休止された場合、それらはメッセージ生成の対象とは見なされません。
宛先でのメッセージ処理の休止については、「宛先でのメッセージ処理の制御」を参照してください。
アプリケーションは、個別の物理宛先に直接アクセスすることで、ロード・バランシングを回避できます。つまり、物理宛先にJNDI名がない場合でも、createQueue()メソッドまたはcreateTopic()メソッドを使用して参照することができます。
共通分散宛先や重み設定された分散宛先のメンバーに直接アクセスする方法については、『Oracle WebLogic Server JMSのプログラミング』の分散宛先メンバーへのアクセスに関する項を参照してください。
アプリケーションにおいて、分散宛先を使用して、複数の物理宛先間でプロデューサやコンシューマを分散、つまりバランスさせることは行っても、メッセージが作成されるたびにロード・バランシングの決定を行いたくない場合は、「ロード・バランシングの有効化」パラメータを無効化した状態で接続ファクトリを使用します。分散宛先においてメッセージの負荷が適正に分散されるようにするには、プロデューサによって使用される初期の物理宛先(キューまたはトピック)が、物理宛先メンバーによって常にランダムに選択される必要があります。
接続ファクトリでのロード・バランシングを無効化するには:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項の説明に従って、「JMS接続ファクトリ」→「構成」→「全般」ページに移動します。
次のガイドラインに従って、「ロード・バランシングの有効化」フィールドを設定します。
ロード・バランシングを有効化 = True
Queue.sender.send()メソッドでは、分散キュー・メンバー間での呼出しごとに、匿名でないプロデューサがロード・バランシングされます。
TopicPublish.publish()メソッドでは、「ロード・バランシングを有効化」設定にかかわりなく、匿名でないプロデューサが呼出しごとに常に同じ物理的なトピックに固定されます。
ロード・バランシングを有効化 = False
プロデューサは失敗するまで常に同じ物理宛先に対して生成します。失敗すると、新しい物理宛先が選択されます。
「保存」をクリックします。
|
注意: 実装によっては、「サーバー・アフィニティの有効化」属性の設定が分散宛先のロード・バランシングのプリファレンスに影響することがあります。詳細は、「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響」を参照してください。 |
匿名プロデューサ(作成時に宛先を指定しないプロデューサ)は、宛先を切り替えるたびにロード・バランシングされます。同じ宛先を使用し続けると、匿名でないプロデューサと同じ法則(前述)が適用されます。
表4-1では、接続ファクトリの「サーバー・アフィニティを有効化」パラメータの設定が、分散宛先メンバーのロード・バランシングのプリファレンスに与える影響について説明します。プリファレンス順位は、操作のタイプ、および恒久サブスクリプションまたは永続メッセージが含まれているかどうかによって異なります。
分散宛先の「サーバー・アフィニティを有効化」パラメータは、ClusterMBeanの「デフォルトのロード・バランス・アルゴリズム」属性によって提供されるサーバー・アフィニティとは異なります。後者は、JMS接続ファクトリでクライアント接続用の初期コンテキスト・アフィニティを作成するためにも使用されます。
詳細は、『Oracle WebLogic Serverクラスタの使用』のEJBとRMIオブジェクトのロード・バランシングに関する項とクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティに関する項を参照してください。
表4-2 サーバー・アフィニティのロード・バランシングのプリファレンス
| 操作 | 「サーバー・アフィニティを有効化」の設定 | ロード・バランシングのプリファレンス |
|---|---|---|
|
True |
|
|
キューの |
False |
|
|
トピックの (注意: 非永続サブスクライバ) |
trueまたはfalse |
|
|
trueまたはfalse |
JMSプロデューサ作成のロード・バランシング用の独立した機能は存在しません。JMSプロデューサは、JMS接続のロード・バランシングまたは固定が行われるサーバーで作成されます。 詳細は、『Oracle WebLogic Serverクラスタの使用』のEJBとRMIオブジェクトのロード・バランシングに関する項とクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティに関する項を参照してください。 |
|
|
True |
|
|
|
False |
|
|
|
True |
|
|
非永続メッセージ
|
False |
|
|
セッション・プール・キューおよびトピックの |
trueまたはfalse |
ローカル・メンバーのみ 注意: セッション・プールは現在ほとんど使用されていません。理由は、Java EE仕様の必須の部分ではないこと、JTAユーザー・トランザクションをサポートしていないこと、そして大部分がメッセージドリブンBean (MDB)に取ってかわられたことです。MDBの方が簡単で管理しやすく、高機能です。 |
サービス移行機能を利用するクラスタリングされたJMS実装では、JMSサーバーとその分散宛先メンバーを、クラスタ内の別のWebLogic Serverインスタンスに手動で移行できます。サービスの移行は、定期的なシステム保守の際や、クラスタ内のサーバーに障害が発生した際に実施できます。
ただし、移行先のWebLogic Serverに物理宛先すべてを持つJMSサーバーがすでにホストされている場合もあります。そのような場合には、同じWebLogic Serverインスタンスが単一の分散宛先について2つの物理宛先をホストするような状況が生じます。WebLogic Serverインスタンスではそのような分散宛先について複数の物理宛先をホストできるため、これは短期的に見れば許容できる状況です。ただし、こうした状況ではロード・バランシングの効率が低下します。
このような状況では、移行先のWebLogic Serverインスタンス上のJMSサーバーは独立して動作します。これは、2つの宛先インスタンスの結合や、1つのインスタンスの無効化を避けるためです。このようなことが発生すると、メッセージが長時間使用できなくなる場合があります。ただし、長期的な目的は、移行されたJMSサーバーをクラスタ内のさらに別のWebLogic Serverインスタンスに最終的に再移行することにあります。
JMSの移行可能ターゲットの構成については、「JMS関連サービスの移行」を参照してください。
JMSプロデューサおよびJMSコンシューマのJMS接続をホストしているサーバー・インスタンスに障害が発生した場合、これらの接続を使用しているすべてのプロデューサとコンシューマは閉じられ、クラスタ内の別のサーバー・インスタンスで再作成されません。また、JMS宛先をホストしているサーバー・インスタンスに障害が発生した場合、その宛先のすべてのJMSコンシューマが閉じられ、クラスタ内の別のサーバー・インスタンスでは再作成されません。
キュー・プロデューサが作成された分散キュー・メンバーに障害が発生したが、プロデューサのJMS接続が存在するWebLogic Serverインスタンスがまだ実行されている場合、プロデューサは閉じられず、WebLogic JMSはロード・バランシング・オプションが有効になっているかどうかに関係なく別の分散キュー・メンバーにフェイルオーバーします。
WebLogic Serverの障害から回復する手順については、『Oracle WebLogic Server JMSのプログラミング』のサーバー障害からの回復に関する項を参照してください。
クライアントIDポリシーは、1つ以上のJMS接続がクラスタ内で同一のクライアントIDを使用できるかどうかを指定します。このポリシーの有効な値は次のとおりです。
RESTRICTED: デフォルトです。このポリシーを使用する接続は、クラスタ内で特定のクライアントIDの所定の時間に1つのみ存続できます(接続が所定のクライアントIDを使用してすでに存在する場合、このポリシーを同一クライアントIDと併用して新しい接続を作成しようとする試行は、例外を表示して失敗します)。
UNRESTRICTED: このポリシーを使用して作成された接続は、他の制限/無制限接続がすでに同一クライアントIDを使用する場合でも、任意のクライアントIDを指定できます。恒久サブスクリプションが無制限クライアントIDを使用して作成されるとき、そのサブスクリプションはweblogic.jms.extensions.WLSession.unsubscribe(Topic topic, String name)を使用してのみクリーンアップできます。『Oracle WebLogic Server JMSのプログラミング』のサブスクリプションの管理に関する項を参照してください。
(使用するアプリケーションに排他的クライアントIDが必要にならないかぎり)特にサブスクリプション(恒久/非恒久)を共有する場合は、新しいアプリケーションに対してはクライアントIDポリシーをUnrestrictedに設定することをお薦めします。異なるクライアントIDポリシーを使用して作成されたサブスクリプションは、常に単独のサブスクリプションとして扱われます。Oracle WebLogic Server MBeanリファレンスのClientIdPolicyに関する項を参照してください。
WebLogicコンソールを使用した接続ファクトリ上でクライアントIDポリシーを設定する場合、Oracle WebLogic Server管理コンソール・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項を参照してください。接続ファクトリ設定は、Oracle WebLogic Server APIリファレンスのWLConnectionインタフェースのsetClientIDPolicyメソッドを使用して、プログラム的にオーバーライドされます。
|
注意: JMS接続ランタイム・オブジェクト上のクライアントIDポリシーのプログラムによる変更(オーバーライド)は、該当する特定の接続インスタンスおよび当該接続の存続期間中のみ有効です。接続ランタイム・オブジェクトへのいかなる変更も、基礎となるJMSモジュール記述子で定義される対応するJMS接続ファクトリ構成によって保存/反映されません。 |
クライアントIDポリシーを使用する方法の詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項。
『Oracle WebLogic Server JMSのプログラミング』の拡張パブリッシュ/サブスクライブ・アプリケーションの開発に関する項
サブスクリプション共有ポリシーは、サブスクライバがサブスクリプションを同一接続上の他のサブスクリプションを共有できるかどうかを指定します。このポリシーの有効な値は次のとおりです。
Exclusive: デフォルトです。この接続ファクトリを使用して作成されるすべてのサブスクライバは、サブスクリプションを他のサブスクリプションと共有できません。
Sharable: この接続ファクトリを使用して作成されたサブスクライバは、サブスクライバが同一の接続ファクトリまたは異なる接続ファクトリのどちらを使用して作成されたかに関係なく、サブスクリプションを他のサブスクライバと共有できるようになります。コンシューマは、同一のクライアントIDとクライアントIDポリシーを持つ場合にのみ非恒久サブスクリプションを共有できます。コンシューマは、同一のクライアントID、クライアントIDポリシー、およびをサブスクリプション名を持つ場合にのみ恒久サブスクリプションを共有できます。
WebLogic JMSアプリケーションは、javax.jms.Connectionインスタンスをweblogic.jms.extension.WLConnectionにキャストしてsetSubscriptionSharingPolicy(String)を呼び出すことによって、接続ファクトリ構成上で指定されるサブスクリプション共有ポリシーをオーバーライドできます。
共有可能なサブスクリプション共有ポリシーを使用する大半のアプリケーションは、同一クライアントIDを使用する複数の接続が存続できることを保証するために無制限クライアントIDポリシーも使用できます。
同一クライアントIDおよびサブスクリプション名を持つ2つの恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。同様に、同一クライアントIDを持つ2つの共有可能な非恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。
サブスクリプション共有ポリシーを使用する方法の詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・ヘルプの接続ファクトリ・サブスクリプション共有ポリシーの構成に関する項。
『Oracle WebLogic Server JMSのプログラミング』の拡張パブリッシュ/サブスクライブ・アプリケーションの開発に関する項
