JMS の管理

以下の節では、WebLogic Server の Java Message Service (JMS) を管理する方法について説明します。

• JMS と WebLogic Server

• JMS のコンフィグレーション

• JMS のモニタ

• JMS のチューニング

• 分散送り先のコンフィグレーション

• WebLogic Server の障害からの回復

 

---

JMS と WebLogic Server

JMS は、エンタープライズ メッセージング システムにアクセスするための標準の API です。具体的な WebLogic JMS の機能は以下のとおりです。

• メッセージング システムを共有する Java アプリケーション同士でメッセージを交換できます。

• メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になります。

次の図は、WebLogic JMS によるメッセージングの仕組みを示しています。

図9-1 WebLogic Server JMS のメッセージング

 

図で示されているように、WebLogic JMS はプロデューサ アプリケーションからメッセージを受信し、受け取ったメッセージをコンシューマ アプリケーションに配信します。

 

---

JMS のコンフィグレーション

Administration Console を使用して、以下のコンフィグレーション属性を定義します。

• JMS サーバを作成し、JMS サーバのデプロイ先となる WebLogic Server インスタンスまたは移行できる対象に割り当てます。

• JMS サーバ、接続ファクトリ、送り先 (物理的なキューとトピック)、分散送り先 (クラスタ内の物理的なキューおよびトピック メンバーの集合)、送り先テンプレート、(送り先キーを使用した) 送り先のソート順指定、永続ストレージ、ページング ストア、セッション プール、および接続コンシューマを作成またはカスタマイズします。

• カスタム JMS アプリケーションを設定します。

• しきい値と割当を定義します。

• サーバのクラスタ化、並行メッセージ処理、送り先のソート順指定、永続的なメッセージング、メッセージ ページング、フロー制御、分散送り先へのロード バランシングなど、必要な JMS 機能を有効にします。

WebLogic JMS では、一部のコンフィグレーション属性に対して、デフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。コンフィグレーション属性に対して無効な値を指定した場合や、デフォルト値が存在しない属性に対して値を指定しなかった場合は、再起動時に JMS が起動されません。Examples サーバには、サンプル コンフィグレーションとして examplesJMSServer が用意されています。Examples サーバの起動については、『インストール ガイド』の「サンプル サーバ、Pet Store サーバ、および Workshop サンプル サーバの起動」を参照してください。 また、WebLogic Server の起動と JMS のコンフィグレーションでは、基本的な JMS 実装を手動でコンフィグレーションする手順が説明されています。

『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの移植」で説明されているように、WebLogic JMS アプリケーションを WebLogic Server の以前のリリースから移植する場合、コンフィグレーション情報は自動的に変換されます。

WebLogic JMS 属性をコンフィグレーションするには、以降の節で説明されている手順に従います。また JMS オブジェクトを作成およびコンフィグレーションするには、Administration Console オンライン ヘルプの手順に従います。

WebLogic JMS をコンフィグレーションしたら、アプリケーションで JMS API を使用してメッセージの送受信ができるようになります。WebLogic JMS アプリケーションの開発の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

注意: WebLogic JMS のコンフィグレーション プランを支援するために、『WebLogic JMS プログラマーズ ガイド』にはコンフィグレーション チェックリストがあります。このチェックリストを使用して、属性の要件や各種 JMS 機能をサポートするオプションを検討できます。

ドメインの相互運用性を実現するための JMS リソースの命名規則

WebLogic ドメイン内では、サーバ インスタンス、マシン、クラスタ、仮想ホストなど、すべてのリソース タイプにユニークな名前を付ける必要があります。また、これらをドメインと同じ名前にすることはできません。 ユニークな名前を付けるという規則は、単一の WebLogic ドメイン環境であるかマルチドメイン環境であるかに関係なく、すべての JMS リソースにも適用されます。

単一ドメイン環境の JMS リソースの命名規則

WebLogic JMS ドメイン内の相互運用性を実現するために、スタンドアロンであるか、サーバ インスタンスがクラスタ化されているかに関係なく、リソースにはユニークな名前を付けるという規則がすべてのコンフィグレーション可能な JMS オブジェクト (JMS サーバ、ストア (ファイルまたは JDBC)、テンプレート、接続ファクトリ、セッション プール、接続コンシューマなど) に適用されます。 たとえば、同じ名前を持つ 2 つの JMS サーバ (myJMSServer など) を、ドメイン内の 2 つの異なるサーバ インスタンスに割り当てることはできません。

JMS のクラスタ化の仕組みに関する詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS のクラスタ化のコンフィグレーション」を参照してください。

ただし、以下に示すように、ドメイン内ではユニークな名前を付けるという規則は、ドメイン内の異なる JMS サーバにある JMS キューおよび JMS トピックの送り先には適用されません。

• キューの送り先には異なる JMS サーバ上の他のキューと同じ名前を使用でき、トピックの送り先には異なる JMS サーバ上の他のトピックと同じ名前を使用できる。

• キューの送り先にはトピックの送り先と同じ名前は使用できず、キューおよびトピックに他のコンフィグレーション可能なオブジェクトと同じ名前を使用することもできない。

マルチドメイン環境の JMS リソースの命名規則

JMS 接続ファクトリという例外を除き、WebLogic JMS リソースの単一ドメイン環境における命名規則は、メッセージング ブリッジを使用して他の WebLogic ドメインにアクセスする場合にドメイン間の相互運用性を実現するためにも適用されます。 この規則は、WebLogic Server の異なるリリースのドメインも対象としています。

たとえば、mydomain61 という名前のバージョン 6.1 ドメインに myserver というサーバ インスタンスがすでにある場合は、mydomain70 というバージョン 7.0 ドメインに myserver という WebLogic Server インスタンスを作成することはできません。 同様に、JMS のサブシステム レベルにおいて、別々のドメインにある場合であっても、名前が同じ 2 つの JMS サーバまたはストアを持つことはできません。

したがって、WebLogic ドメイン間の相互運用を行う際には以下の規則に従う必要があります。

• ドメイン名はすべて、企業全体に渡ってユニークでなければならない。

• WebLogic Server のインスタンス名はすべて、ドメイン内およびすべての相互運用するドメインに渡ってユニークでなければならない。

• JMS サーバ名はすべて、ドメイン内およびすべての相互運用するドメインに渡ってユニークでなければならない。

• 永続メッセージに JMS ストア (ファイルまたは JDBC) が使用されている場合、ストア名はすべて、ドメイン内およびすべての相互運用するドメインに渡ってユニークでなければならない。

複数の WebLogic ドメインと相互運用するようにメッセージング ブリッジをコンフィグレーションする詳細については、メッセージング ブリッジを使用しての WebLogic Server のさまざまなリリースおよびドメインとの相互運用を参照してください。

WebLogic Server の起動と JMS のコンフィグレーション

以下の節では、WebLogic Server および Administration Console の起動方法を概説し、基本的な JMS 実装をコンフィグレーションする手順について説明します。

デフォルトの WebLogic Server の起動

WebLogic Server のデフォルトのロールは管理サーバです。ドメインが 1 つの WebLogic Server のみで構成されている場合は、そのサーバが管理サーバになります。ドメインが複数の WebLogic Server で構成されている場合は、まず管理サーバを起動してから、管理対象サーバを起動します。

管理サーバの起動の詳細については、管理サーバの起動を参照してください。

Administration Console の起動

Administration Console は、WebLogic Server に対する Web ベースの管理者フロントエンド (管理者クライアント インタフェース) です。サーバの Administration Console にアクセスする前に、サーバを起動する必要があります。

Administration Console を使用した WebLogic Server のコンフィグレーションの詳細については、Administration Console の起動と使い方を参照してください。

基本的な JMS 実装のコンフィグレーション

この節では、Administration Console を使用して基本的な JMS 実装をコンフィグレーションする方法について説明します。

1. 左ペインの [サービス] ノードの下の [JMS] ノードをクリックしてリストを展開します。

2. ディスクベースのファイルに永続メッセージを保存するには、JMS ファイル ストアを作成する必要があります。JMS ページング機能を使用する場合は、空きメモリがなくなったときにメッセージ本文を一時的にディスクへスワップするための付加的な「ページング」JMS ストアもコンフィグレーションする必要があります。

   1. JMS ファイル ストアが置かれるファイル システム上のディレクトリを作成します。

   2. 左ペインの [ストア] ノードをクリックしてから、右ペインの [新しい JMS File Store のコンフィグレーション] リンクをクリックします。

   3. [一般] タブで、ストアに名前を付け、ディレクトリを指定し、必要に応じて同期書き込みポリシーを選択して、ファイル ストアがディスクにデータを書き込む方式を決定します。その後、[作成] をクリックします。

   4. 同じ手順を繰り返して、ページング ストアを作成します。

   ストアのコンフィグレーションの詳細については、ストアのコンフィグレーションを参照してください。

3. JDBC でアクセス可能なデータベースに永続メッセージを保存するには、JMS JDBC ストアを作成する必要があります (JDBC 接続プールを作成する必要がある場合は、まず手順 A から D を完了させます。それ以外の場合は、手順 E までスキップできます)。 JMS ページング機能を使用する場合は、空きメモリがなくなったときにメッセージ本文を一時的にディスクへスワップするための付加的な「ページング」JMS ファイル ストアもコンフィグレーションする必要があります。

   1. 左ペインの [JDBC] ノードをクリックして展開します。

   2. 左ペインの [接続プール] ノードをクリックしてから、右ペインの [新しい JDBC Connection Pool のコンフィグレーション] リンクをクリックします。

   3. [コンフィグレーション] タブで、名前、URL、データベース プロパティなどの接続プールの属性を設定します。完了したら、各タブの [適用] をクリックします。

   4. [対象] タブをクリックし、接続プールを WebLogic Server インスタンスにデプロイする場合は [サーバ] タブを、サーバ クラスタにデプロイする場合は [クラスタ] タブを選択します。[選択可] リストから対象を [選択済み] リストに移動させることによって選択し、[適用] をクリックします。

   5. [JMS｜ストア] ノードに戻り、右ペインの [新しい JMSJDBCStore のコンフィグレーション] リンクをクリックします。

   6. JDBC ストアに名前を付け、接続プールとプレフィックス名を選択します。その後、[作成] をクリックします。

   JMS JDBC ストアの使用の詳細については、JMS JDBC ストア についてを参照してください。 JDBC 接続プールのコンフィグレーションの詳細については、Administration Console による JDBC 接続プール、マルチプール、およびデータソースのコンフィグレーションと管理を参照してください。

4. 必要に応じて、同じような属性設定で複数の送り先を定義するための JMS テンプレートを作成します。JMS テンプレートは、一時キューの作成にも必要です。

   1. 左ペインの [テンプレート] ノードをクリックしてから、右ペインの [新しい JMS Template のコンフィグレーション] リンクをクリックします。

   2. [一般] タブでテンプレートに名前を付け、[作成] をクリックします。

   3. 必要に応じて、[しきい値と割当]、[オーバライド]、および [再配信] タブに値を入力します。完了したら、各タブの [適用] をクリックします。

   JMS テンプレートのコンフィグレーションの詳細については、JMS テンプレートのコンフィグレーションを参照してください。

5. JMS サーバをコンフィグレーションするには、次の手順に従います。

   1. 左ペインの [サーバ] ノードをクリックしてから、右ペインの [新しい JMSServer のコンフィグレーション] リンクをクリックします。

   2. [一般] タブでサーバに名前を付け、[ストア]、[ページング ストア]、および [テンプレート] のうち、作成したものを選択します。その後、[作成] をクリックします。

   3. 必要に応じて、[しきい値と割当] タブに値を入力します。完了したら、[適用] をクリックします。

   4. [対象] タブをクリックし、JMS サーバを WebLogic Server インスタンスにデプロイする場合は [サーバ] タブを、移行可能対象サーバにデプロイする場合は [移行できる対象] タブを選択します。[選択可] リストから対象を [選択済み] リストに移動させることによって選択し、[適用] をクリックします。

   JMS サーバのコンフィグレーションの詳細については、JMS サーバのコンフィグレーションを参照してください。

6. JMS 送り先を作成します。JMS 送り先は、キュー (ポイント ツー ポイント) またはトピック (Pub/Sub) です。

   1. 左ペインの [サーバ] ノードの下で、新しい JMS サーバ インスタンスをクリックしてリストを展開し、[送り先] ノードをクリックします。

   2. 右ペインで [新しい JMSQueue のコンフィグレーション] と [新しい JMSTopic のコンフィグレーション] のいずれかのリンクをクリックします。

   3. [一般] タブで、送り先に名前と JNDI 名を付けます。必要に応じて他の属性を入力し、[作成] をクリックします。

   4. 必要に応じて、[しきい値と割当]、[オーバライド]、および [マルチキャスト] タブに値を入力します。完了したら、各タブの [適用] をクリックします。

   送り先のコンフィグレーションの詳細については、送り先のコンフィグレーションを参照してください。

7. 接続ファクトリを作成して JMS クライアントを有効化し、JMS 接続を作成するには、次の手順に従います。

   1. 左ペインの [接続ファクトリ] ノードをクリックして展開し、右ペインの [新しい JMS Connection Factory のコンフィグレーション] リンクをクリックします。

   2. [一般] タブで、接続ファクトリに名前と JNDI 名を付けます。必要に応じて他の属性を入力し、[作成] をクリックします。

   3. 必要に応じて、[トランザクション] および [フロー制御] タブに値を入力します。完了したら、各タブの [適用] をクリックします。

   4. [対象] タブをクリックし、接続ファクトリを WebLogic Server インスタンスにデプロイする場合は [サーバ] タブを、サーバ クラスタにデプロイする場合は [クラスタ] タブを選択します。[選択可] リストから対象を [選択済み] リストに移動させることによって選択し、[適用] をクリックします。

   接続ファクトリのコンフィグレーションの詳細については、接続ファクトリのコンフィグレーションを参照してください。

8. 必要に応じて、[送り先キー] ノードを使用して特定の送り先のソート順を定義します。 詳細については、送り先キーのコンフィグレーションを参照してください。

9. 必要に応じて、[分散送り先] ノードを使用し、物理的な送り先をサーバ クラスタ内に設定された論理的な分散送り先の一部にします。 詳細については、分散送り先のコンフィグレーションを参照してください。

10. 必要に応じて、アプリケーションでメッセージを並行処理するための JMS セッション プール、およびサーバ セッションを取得してメッセージを処理する接続コンシューマ (キューまたはトピック) を作成します。 詳細については、セッション プールのコンフィグレーションおよび接続コンシューマのコンフィグレーションを参照してください。

JMS サーバのコンフィグレーション

JMS サーバは、クライアントの代わりに接続およびメッセージ リクエストを管理するサーバです。JMS サーバを作成するには、Administration Console の [サーバ] ノードを使用して、以下を定義します。

• 以下の一般的なコンフィグレーション属性。

  • JMS サーバの名前。

  • 永続的なメッセージングに必要な永続ストレージ (ファイルまたは JDBC データベース)。JMS サーバに永続ストレージを割り当てない場合、そのサーバでは永続的なメッセージングはサポートされません。JMS ストアのコンフィグレーションの詳細については、ストアのコンフィグレーションを参照してください。

  • ページングに必要なページング ストア (ファイル ストアを推奨)。JMS サーバにページング ストアを割り当てない場合、そのサーバでは永続的なメッセージングはサポートされません。ページングのコンフィグレーションの詳細については、メッセージ ページングのコンフィグレーションを参照してください。

  • 一時的なキューおよびトピックを含むすべての一時的な送り先を作成する場合に使用される一時的なテンプレート。

  注意: JMS サーバの名前は、ドメイン内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

• メッセージおよびバイト数のしきい値と割当 (最大数、最大しきい値と最小しきい値)、およびバイト ページングまたはメッセージ ページングを有効にするかどうか。

• JMS サーバのデプロイ先となる WebLogic Server インスタンスまたは移行できる対象を定義する。

  • サーバ-対象の WebLogic Server が起動すると、JMS サーバも起動します。対象の WebLogic Server が指定されていない場合、JMS サーバは起動しません。

  注意: JMS サーバのデプロイメントは、接続ファクトリやテンプレートのデプロイメントとは異なります。JMS サーバは、単一の WebLogic Server インスタンスまたは移行できる対象 (次項を参照) にデプロイされます。一方、接続ファクトリやテンプレートは、複数のサーバで同時にインスタンス化されます。

  • 移行できる対象-移行できる対象は、JMS など「かならず 1 回」のサービスのホストとなり得る、クラスタ内の複数の WebLogic Server インスタンスを定義します。移行できる対象のサーバが起動すると、JMS サーバもクラスタ内のユーザ指定のサーバ上で起動します。ただし、JMS サーバとその送り先はすべて、WebLogic Server の障害発生に応答して、またはスケジューリングされた移行やシステムの保守のため、クラスタ内の別のサーバに移行することができます。 JMS の移行できる対象のコンフィグレーションの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の管理」を参照してください。

JMS サーバを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS サーバのタスク」を参照してください。

接続ファクトリのコンフィグレーション

接続ファクトリは、JMS クライアントが JMS 接続を作成することを可能にするオブジェクトです。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。 WebLogic JMS には、あらかじめコンフィグレーションされたデフォルトの接続ファクトリ weblogic.jms.ConnectionFactory が用意されています。この接続ファクトリは、サーバごとに記述できます。詳細については、Administration Console オンライン ヘルプの「[サーバ] --> [サービス] --> [JMS]」を参照してください。 もしくは、1 つまたは複数の接続ファクトリを定義およびコンフィグレーションし、あらかじめ定義された属性を使用して、よりアプリケーションに適合する接続を作成できます。ただし、各接続ファクトリにユニークな名前が付けられている場合にかぎります。WebLogic Server では、起動時に接続ファクトリが JNDI スペースに追加され、アプリケーションが WebLogic JNDI を使用して接続ファクトリを取り出します。

クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスを確立するには、各サーバ インスタンスに対してデフォルトの接続ファクトリを有効にするか、1 つまたは複数の接続ファクトリをコンフィグレーションしてクラスタ内の 1 つまたは複数のサーバ インスタンスに割り当てます。これにより、各接続ファクトリを複数の WebLogic Server にデプロイすることが可能となります。 JMS のクラスタ化のコンフィグレーションの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の管理」を参照してください。

接続ファクトリをコンフィグレーションするには、Administration Console の [接続ファクトリ] ノードを使用して、以下を定義します。

• 以下の一般的なコンフィグレーション属性。

  • 接続ファクトリの名前。

  • JNDI ネームスペース内で接続ファクトリにアクセスする場合の名前。

  • 恒久サブスクライバを持つクライアントのクライアント識別子 (クライアント ID)。 恒久サブスクライバの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

  • デフォルトのメッセージ配信属性 (優先度、存続時間、配信時刻、および配信モード)。

  • 非同期セッション向けに存在する未処理のメッセージの最大数とオーバラン ポリシー (マルチキャスト セッションで最大数に達したときに実行されるアクション)。

  • close() メソッドを onMessage() メソッドから呼び出せるかどうか。

  • すべてのメッセージが確認応答されるのか、それとも受信したメッセージのみが確認応答されるのか。

  • 分散送り先の場合は、接続ファクトリで作成された匿名でないプロデューサが、呼び出しごとにロード バランシングの対象となるかどうか。

  • 分散送り先の場合、コンシューマまたはプロデューサのロード バランシングを分散送り先で行うときにサーバ アフィニティを使用するかどうか。

  注意: JMS 接続ファクトリの名前は、ドメイン内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

• トランザクション属性-トランザクションのタイムアウト、Java Transaction API (JTA) ユーザ トランザクションが可能かどうか、トランザクション (XA) キューまたは XA トピック接続ファクトリが返されるのかどうか、およびサーバサイド トランザクションが有効かどうか。

• フロー制御属性-メッセージ プロデューサによってメッセージ フローを調整できます。 フロー制御のコンフィグレーションの詳細については、メッセージのフロー制御の確立を参照してください。

• WebLogic Server インスタンスまたはサーバ クラスタの対象を定義する。対象を定義することにより、接続ファクトリがデプロイされる可能性のあるサーバ、グループ、およびクラスタのセットを限定できます。

  • サーバ-接続ファクトリのデプロイ先となる単一の WebLogic Server インスタンスを対象として定義します。

  • クラスタ-クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスをサポートするための、接続ファクトリのデプロイ先となるクラスタを対象として定義します。

デフォルトの接続ファクトリ weblogic.jms.ConnectionFactory では、すべてのコンフィグレーション属性がデフォルト値に設定されています。デフォルトの接続ファクトリの定義がアプリケーションに適用できる場合は、さらに接続ファクトリのコンフィグレーションを行う必要はありません。

注意: デフォルトの接続ファクトリを使用する場合は、接続ファクトリがデプロイされる可能性のある WebLogic Server を限定できない。特定のサーバを対象にする場合は、新しい接続ファクトリを作成し、適切なサーバ対象を指定してください。

接続ファクトリを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「接続ファクトリのタスク」を参照してください。

接続ファクトリの属性の中には、動的にコンフィグレーションできるものもあります。動的な属性が実行時に変更された場合、新しく設定された値は新規接続に対してのみ有効になります。既存の接続の動作には影響しません。

送り先のコンフィグレーション

送り先では、JMS サーバのキュー (ポイント ツー ポイント) かトピック (Pub/Sub) かが識別されます。JMS サーバを定義したら、各 JMS サーバに 1 つのまたは複数の送り先をコンフィグレーションします。

送り先は、明示的にコンフィグレーションすることも、送り先テンプレートを使用してコンフィグレーションすることもできます。送り先テンプレートを使用すると、似た属性設定を持つ複数の送り先を定義できます (JMS テンプレートのコンフィグレーションを参照)。

注意: また、クラスタ内の単一の分散送り先のメンバーとして、複数の物理的送り先をコンフィグレーションすることもできます。したがって、クラスタ内で 1 つのインスタンスがダウンした場合に、同じ送り先の他のインスタンスで JMS プロデューサおよびコンシューマにサービスを提供できます。 詳細については、分散送り先のコンフィグレーションを参照してください。

送り先を明示的にコンフィグレーションするには、Administration Console の [送り先] ノードを使用して、以下のコンフィグレーション属性を定義します。

• 以下の一般的なコンフィグレーション属性。

  • 送り先の名前とタイプ (キューまたはトピック)

  • JNDI ネームスペース内で送り先にアクセスする場合の名前

  • 格納されている永続的メッセージに対するストアの有効化または無効化

  • 送り先の作成に使用される JMS テンプレート

  • 特定の送り先に対してソート順を定義する場合に使用されるキー

  注意: JMS 送り先の名前は、ドメイン内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

• メッセージおよびバイト数のしきい値と割当 (最大数、最大しきい値と最小しきい値)、およびバイト ページングまたはメッセージ ページングを送り先で有効にするかどうか。

• オーバーライド可能なメッセージ属性 (優先度、存続時間、配信時刻、および配信モード)

• 再配信遅延のオーバーライド、再配信制限、エラーの送り先などのメッセージ再配信属性

• マルチキャスト アドレス、存続時間 (TTL)、ポートなどのマルチキャスト属性 (トピックの場合のみ)

送り先を作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS 送り先のタスク」を参照してください。

送り先の属性の中には、動的にコンフィグレーションできるものもあります。属性が実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。

JMS テンプレートのコンフィグレーション

JMS テンプレートを使用することによって、似た属性設定を持つ複数の送り先を効率的に定義できます。JMS テンプレートには、以下のような利点があります。

• 新しい送り先を定義するたびにすべての属性設定を再入力する必要がない (JMS テンプレートを使用しても、新しい値を割り当てる任意の設定をオーバーライドできます)。

• テンプレートを変更するだけで、共有される属性設定を動的に変更可能。

JMS テンプレートのコンフィグレーション属性を定義するには、Administration Console の [テンプレート] ノードを使用します。JMS テンプレートに対してコンフィグレーションできる属性は、送り先に対してコンフィグレーションされる属性と同じです。これらのコンフィグレーション属性は、それらを使用する送り先によって継承されます。ただし、以下の例外があります。

• JMS テンプレートを使用する送り先で属性のオーバーライド値が指定される場合は、そのオーバーライド値が使用される。

• JMS テンプレートを使用する送り先で属性のメッセージ再配信値が指定される場合は、その再配信値が使用される。

• [名前] 属性は、送り先によって継承されない。この名前は JMS テンプレートでのみ有効です。すべての送り先ではユニークな名前を明示的に定義しなければなりません。

  注意: JMS テンプレートの名前は、ドメイン内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

• [JNDI 名]、[ストアを有効化]、[テンプレート] の各属性は、JMS テンプレートでは定義されない。

• [マルチキャスト] 属性は、トピックだけに適用されるので、JMS テンプレートでは定義されない。

送り先に対して明示的に定義されない属性には、デフォルト値が割り当てられます。デフォルト値が存在しない場合は、必ず、JMS テンプレートで値を指定するか、または送り先の属性のオーバーライド値として値を指定します。そうしないと、コンフィグレーション情報は不備な状態のままとなります。その場合、WebLogic JMS コンフィグレーションは失敗し、WebLogic JMS が起動しません。

JMS テンプレートを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS テンプレートのタスク」を参照してください。

送り先キーのコンフィグレーション

特定の送り先に対してソート順を定義するには、送り先キーを使用します。

送り先キーを作成するには、Administration Console の [送り先キー] ノードを使用して、以下のコンフィグレーション属性を定義します。

• 送り先キーの名前

• ソートするプロパティ名

• 予想されるキー タイプ

• ソートする方向 (昇順または降順)

送り先キーを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「送り先キーのタスク」を参照してください。

ストアのコンフィグレーション

永続ストレージは、永続的なメッセージングに使用されるファイルまたはデータベースで構成されます。ファイル ストアまたはデータベース ストアを作成するには、Administration Console の [ストア] ノードを使用して、以下のコンフィグレーション属性を定義します。

• JMS 永続ストレージの名前

• MS ファイル ストアの場合-メッセージが保存される場所へのパスを指定します。必要に応じて、ディスク書き込みポリシーを選択します (JMS ファイル ストアの同期書き込みポリシーのコンフィグレーションを参照)。

• JMS JDBC データベース ストアの場合-複数のインスタンスと共に使用する JDBC 接続プールとデータベース テーブル名のプレフィックスを指定します (JMS JDBC ストア テーブルのプレフィックスを参照)。

  注意: JMS ストアの名前は、ドメイン内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

警告: トランザクション (XA) 接続プールを、JDBC データベース ストアで使用するようにコンフィグレーションすることはできません。 詳細については、JMS JDBC トランザクションを参照してください。

JMS 永続ストレージに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープ サイズを、現在 JMS 永続ストレージに格納されているメッセージ数に比例するよう増加させてください。その後、サーバを再起動してください。 ヒープ サイズの設定の詳細については、『BEA WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic Server アプリケーションのチューニング」を参照してください。

ストアを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS ファイル ストアのタスク」(ファイル ストアに関する情報)、および「JMS JDBC ストアのタスク」(JDBC データベース ストアに関する情報) をそれぞれ参照してください。

JMS JDBC ストア について

JMS では、JDBC を使用することで、指定された JDBC 接続プールからアクセスできるデータベースに永続的メッセージを格納できます。JMS データベースには、JDBC ドライバからアクセスできる任意のデータベースを指定できます。WebLogic JMS では、以下のデータベースに対応する一部のドライバが検出されます。

• Pointbase

• Microsoft SQL (MSSQL) Server

• Oracle

• Sybase

• Cloudscape

• Informix

• IBM DB2

• Times Ten

weblogic.jar ファイル内の weblogic/jms/ddl ディレクトリには、これらのデータベースに対応する JMS DDL ファイルが含まれています。JMS DDL ファイルは実際にはテキスト ファイルであり、JMS データベース テーブルを作成する SQL コマンドを含んでいます。異なるデータベースを使用するには、これらの .ddl ファイルのいずれかをコピーして編集するだけです。

注意: WebLogic Server 配布キットに用意されている JMS サンプルは、PointBase Java データベースで動作するように設定されています。WebLogic Server には、PointBase の評価版が付属しており、demoPool データベースが用意されています。

既存の JMS JDBC ストアが破損している場合、utils.Schema ユーティリティを使用して再生成できます。 詳細については、『WebLogic JMS プログラマーズ ガイド』の「JDBC データベース ユーティリティ」を参照してください。

JMS JDBC トランザクション

JMS JDBC ストアで使用するように、トランザクション (XA) 接続プールをコンフィグレーションすることはできません。JMS では 非 XAResource ドライバを使用する JDBC 接続プールを使用しなければなりません (XA ドライバまたは JTS ドライバは使用できません)。JMS は JDBC ドライバの上で XA をサポートします。

これは、WebLogic JMS には独自のリソース マネージャがあるためです。つまり、JMS 自身が XAResource を実装し、(メッセージがデータベースに格納されている場合でも) データベースに依存しないでトランザクションを処理します。従って、JMS とデータベースを使用する場合は (そのデータベースが JMS メッセージが格納されているデータベースと同じでも)、常に 2 フェーズ コミット トランザクションになります。 WebLogic JMS でのトランザクションの使い方については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS によるトランザクションの使い方」を参照してください。

パフォーマンスの点から見ると、データベース操作に使用される JDBC 接続プールが JMS キューと同じ WebLogic Server 上にある場合、パフォーマンスが向上する可能性があります。トランザクションは依然として 2 フェーズですが、より小さいネットワーク オーバーヘッドで処理されるためです。また、JMS JDBC ストアではなく JMS ファイル ストアを使用することによっても、パフォーマンスが向上する場合があります。

JMS JDBC セキュリティ

必要に応じて、JDBC 接続プールのリソースを制限することもできます。以前のバージョンの WebLogic Server では、ACL を使って WebLogic リソースを保護していました。WebLogic Server バージョン 7.0 では、WebLogic リソースへの「アクセス権は誰が持つか」という問いに、セキュリティ ポリシーが答えます。セキュリティ ポリシーは、WebLogic リソースとユーザ、グループ、またはロールの間の関連付けを定義するときに作成します。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。 すべての WebLogic Server リソースに対してセキュリティを設定する方法に関する詳細については、Administration Console オンライン ヘルプの「WebLogic リソースの保護の設定」を参照してください。

JMS JDBC ストアでの Oracle 主キーの使用

Oracle データベースの場合、Oracle のアドバンスト レプリケーションでは LONG または LONG RAW データ型カラムを持つテーブルはレプリケートできませんが、代わりに主キーの使用が必要になります。 このため、デフォルトの Oracle DDL ファイルを修正して、JMS JDBC ストアで使用される JMSStore テーブルに手動で主キーを追加します。

jms_oracle.ddl ファイルが事前にコンフィグレーションされ、WL_HOME/server/lib/weblogic.jar ファイル (WL_HOME は WebLogic Server がインストールされている最上位ディレクトリ) にある WebLogic CLASSPATH で指定されています。

JMSStore および JMSState テーブルがすでに存在する場合は、これらのテーブルは削除され、修正された DDL ファイルを使用するように再作成される必要があります。

1. JDK で用意されている JAR ユーティリティを使用して、次のコマンドで JMS ストア DDL ファイルを weblogic/jms/ddl ディレクトリに抽出します。

   jar xf weblogic.jar /weblogic/jms/ddl

2. 次のように、jms_oracle.ddl テキスト ファイルを編集します。

   1. CREATE TABLE JMSSTORE エントリを見つけ、次のように PRIMARY KEY NOT NULL を追加します。

      CREATE TABLE JMSStore (recordHandle int PRIMARY KEY NOT NULL, recordState int, record LONG RAW);

   2. 次の CREATE INDEX エントリを削除します。

      CREATE INDEX JMSMSGQ_X ON JMSStore (recordHandle);

3. DDL ファイルへの変更を保存します。

4. 『WebLogic JMS プログラマーズ ガイド』の「JDBC データベース ストアの再生成」にある手順に従って、カスタマイズされた jms_oracle.ddl ファイルを使用する JMS ストア テーブルを再生成します。

JMS JDBC ストア テーブルのプレフィックス

JMS データベースには、自動的に生成され、JMS 内部で使用されるシステム テーブルが 2 つあります。

• <prefix>JMSStore

• <prefix>JMSState

プレフィックス名は、この永続ストレージ内の JMS テーブルを識別します。ユニークなプレフィックスを指定すると、同一データベース内に複数のストアが存在できます。プレフィックスは、JMS JDBC ストアをコンフィグレーションする際に Administration Console でコンフィグレーションします。プレフィックスは、DBMS で完全修飾名が必要な場合、または 2 つの WebLogic Server の JMS テーブルを区別する必要がある (1 つの DBMS で複数のテーブルを格納できるようにする) 場合にテーブル名の前に付けられます。

警告: データに障害が発生するので、2 つのJMS JDBC ストアを同じデータベース テーブルで使用することはできません。

プレフィックスは、JMS テーブル名に付加されたときに有効なテーブル名になるように、次の形式で指定します。

[[[catalog.]schema.]prefix]JMSStore

catalog は DBMS が参照するシステム テーブルのセットを識別し、schema はテーブル オーナの ID に変換します。たとえば JMS 管理者は、次のようにプロダクション データベースで販売部門用の固有のテーブルを保持できます。

[[[Production.]JMSAdmin.]Sales]JMSStore

このテーブルは、JMSAdmin スキーマの Production カタログに作成され、SalesJMSStore という名前が付けられます。

注意: Oracle などの一部の DBMS ベンダの場合、設定または選択するカタログがないので、このフォーマットは [[schema.]prefix] となります。詳細については、DBMS のマニュアルで完全修飾テーブル名の作成および使用方法を参照してください。

JMS JDBC ストア向けの JDBC 接続プールの推奨設定

WebLogic Server の堅牢な JDBC 接続プールは、データベースに障害が発生した場合、復旧後に自動的に再接続します。このため、WebLogic Server を再起動する必要はありません。この機能を活用し、JMS JDBC ストアをより堅牢にするには、JMS JDBC ストアに関連付けられている JDBC 接続プールの以下の属性をコンフィグレーションします。

TestConnectionsOnReserve="true"
TestTableName="SYSTABLES"

JDBC のデフォルトのテスト テーブル名に関する詳細については、Administration Console オンライン ヘルプの「[JDBC 接続プール] --> [コンフィグレーション] --> [テスト]」で、接続をテストするためのオプションを参照してください。

セッション プールのコンフィグレーション

サーバ セッション プールを使用すると、アプリケーションで複数のメッセージを並行して処理できます。JMS サーバを定義したら、必要に応じて各 JMS サーバに 1 つのまたは複数のサーバ セッション プールをコンフィグレーションします。

Administration Console の [セッション プール] ノードを使用して、以下のコンフィグレーション属性を定義します。

• サーバ セッション プールの名前。セッション プールの名前は、ドメイン内でユニークでなければなりません。詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

• サーバ セッション プールが関連付けられ、セッションを作成する場合に使用される接続ファクトリ。

• 並行して複数のメッセージを受信および処理する場合に使用されるメッセージ リスナ クラス。

• トランザクション属性 (確認応答モード、セッション プールでトランザクション セッションを作成するかどうか)

• 並行セッションの最大数

セッション プールを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「セッション プールのタスク」を参照してください。

セッション プールの属性の中には、動的にコンフィグレーションできるものもありますが、新しい値はセッション プールが再起動されるまで有効になりません。

接続コンシューマのコンフィグレーション

接続コンシューマは、サーバ セッションを取り出し、メッセージを処理するキュー (ポイント ツー ポイント) またはトピック (Pub/Sub) です。セッション プールを定義したら、各 JMS サーバに 1 つまたは複数の接続コンシューマをコンフィグレーションします。

接続コンシューマをコンフィグレーションするには、Administration Console の [セッション プール] ノードを使用して、以下のコンフィグレーション属性を定義します。

• 接続コンシューマの名前。接続コンシューマの名前は、ドメイン内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

• 接続コンシューマによって蓄積されるメッセージの最大数。

• メッセージをフィルタ処理する場合に使用される JMS セレクタ式。 セレクタの定義については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

• 接続コンシューマがリスン対象とする送り先

接続コンシューマを作成およびコンフィグレーションする手順と、接続コンシューマの各コンフィグレーション属性の詳細については、Administration Console オンライン ヘルプの「接続コンシューマのタスク」を参照してください。

 

---

JMS のモニタ

Administration Console を使用すると、JMS サーバ、接続、セッション、送り先、メッセージ プロデューサ、メッセージ コンシューマ、サーバ セッション プール、恒久サブスクライバといった JMS オブジェクトに関する統計をモニタできます。

サーバの実行中は、JMS 統計は増え続けます。統計は、サーバを再起動するときにのみリセットされます。

注意: WebLogic Server への JMS 接続のモニタについては、Administration Console オンライン ヘルプの「サーバ」を参照してください。

JMS オブジェクトのモニタ

アクティブな JMS サーバ、送り先、およびセッション プールの実行時情報を表示するには、次の手順に従います。

1. Administration Console を起動します。

2. 左ペインの [サービス] の下にある [JMS] ノードをクリックし、JMS サーバのリストを展開します。

3. 左ペインの [JMS] の下にある [サーバ] ノードをクリックします。

   JMS サーバの情報が、右ペインに表示されます。

4. リストまたは右ペインに表示されている JMS サーバから、モニタする JMS サーバを選択します。

5. [モニタ] タブを選択して、以下のテキスト リンクを表示します。

   • [すべてのアクティブ JMS サーバのモニタ]

   • [すべてのアクティブな JMS の送り先のモニタ]

   • [すべての JMSSession Pool Runtimes のモニタ]

6. 適切なテキスト リンクをクリックして、JMS オブジェクトのモニタ データを表示します。

注意: 分散送り先をモニタする場合、そのトピックまたはキュー メンバーに対するプロキシ トピック メンバーまたはシステム サブスクリプションが表示されることがあります。 詳細については、分散送り先のシステム サブスクリプションとプロキシ トピック メンバーのモニタを参照してください。

恒久サブスクライバのモニタ

送り先トピックで動作している恒久サブスクライバを表示するには、次の操作を行います。

1. JMS オブジェクトのモニタで説明されている手順 1 〜 3 に従います。

2. 左ペインの [サーバ] の下にある [送り先] ノードをクリックし、JMS トピックおよびキューのリストを展開します。

   JMS 送り先情報が右ペインに表形式で表示されます。[恒久サブスクライバ] カラムには、表に示されている送り先トピックに対して実行されている恒久サブスクライバの数が表示されます。

3. 特定のトピックの恒久サブスクライバ情報を表示するには、目的のトピックの [恒久サブスクライバ] のアイコン (または実際の数) をクリックします。

分散送り先のシステム サブスクリプションとプロキシ トピック メンバーのモニタ

WebLogic Server 7.0 の特定の JMS コンフィグレーションでは、分散送り先が、トピック メンバーまたはキュー メンバー間に、「プロキシ トピック メンバー」と「システム サブスクリプション」を自動的に作成することがあります。その場合、分散送り先のメンバーをモニタすると、システム サブスクリプションとプロキシ トピック メンバーが MBean の統計に現れ、Administration Console に表示されます。また、分散送り先メンバーの恒久サブスクリプション名とコンシューマ数にも現れます。

システム サブスクリプションとプロキシ トピック メンバーの動作について以下に示します。

• 分散 トピック プロキシ メンバー - WebLogic Server インスタンスで JMS 接続ファクトリがコンフィグレーションされているが、リモートの分散トピックに対応するローカルの分散トピック メンバーをホストするようにコンフィグレーションされていない場合、その WebLogic Server インスタンスは、リモートの分散トピックに対応するローカルのプロキシ トピック メンバーを自動的に作成してホストすることがあります。これは、その分散トピックに対する最初の非恒久サブスクリプションが、サーバの接続ファクトリで作成されるときに発生します。動的に作成されるプロキシ トピック メンバーは、動的に作成される JMS サーバ内に置かれます。手動でコンフィグレーションされる各分散トピック メンバーは、動的に作成されるプロキシ トピック メンバーごとにシステム サブスクリプションを作成します。次に、非恒久コンシューマがプロキシ トピック メンバー上に作成されます。

• 分散トピック システム サブスクリプション - システム サブスクリプションは、コンフィグレーション済みの分散送り先メンバー間で、メッセージを転送するために使用されます。たとえば、1 つの分散トピックの中に n 個のメンバーがある場合、各メンバーは少なくとも n-1 個のシステム サブスクライバを持っています。さらに、各プロキシ トピック メンバーに対して、各分散トピック メンバー上に 1 つのシステム サブスクリプションがあります。

• 分散キュー システム サブスクリプション - 分散キューの [転送の遅延] 属性を、(デフォルト値の -1 秒を変更して) 有効にしている分散キュー メンバーも、システム サブスクリプションを作成することがあります。システム サブスクライバは、コンシューマを持たないキュー メンバーから、コンシューマを持つキュー メンバーへメッセージを転送するために使用されます。

• 恒久システム サブスクリプション - 分散トピック メンバーに対して JMS ファイル ストアまたは JDBC ストアがコンフィグレーションされている場合、恒久サブスクライバとしてシステム サブスクリプションが作成されます。システム サブスクリプションは、Administration Console に名前で表示されます。

 

---

JMS のチューニング

以下の節では、WebLogic JMS で利用できる管理パフォーマンス チューニング機能を実装することによって、アプリケーションを最大限に活用する方法について説明します。

• 永続ストレージ

• メッセージ ページングのコンフィグレーション

• メッセージのフロー制御の確立

• 分散送り先のチューニング

永続ストレージ

以降の節では、WebLogic Server JMS で永続ストレージを使用する場合のチューニング オプションについて説明します。

JMS ファイル ストアの同期書き込みポリシーのコンフィグレーション

WebLogic JMS ファイル ストアでは、デフォルトで同期書き込みを使用することで最新のメッセージの整合性を保証します。通常、同期書き込みを無効にすると、ファイル ストアのパフォーマンスは大幅に向上します。その代わり、オペレーティング システムがクラッシュしたり、ハードウェアの障害が発生したりした場合には、メッセージがトランザクション対応であっても、送信したメッセージが失われたり、同じメッセージを重複して受信したりする可能性があります。オペレーティング システムでは通常のシャットダウン時に未処理の書き込みをすべてフラッシュするので、OS をシャット ダウンするだけではこうしたエラーは発生しません。こうしたエラーは、ビジー状態のサーバの電源を遮断することでエミュレートできます。

注意: ファイル ストアが非永続的なメッセージのディスクへのページングのために排他的に使用されている場合、同期書き込みポリシーは無視されます。

表 9-1 は、WebLogic Server 上で実行されているすべての JMS ファイル ストアの同期書き込みポリシーをコンフィグレーションする際のオプションについて説明しています。

表9-1 同期書き込みポリシーの属性

属性	説明
Disabled	ファイル ストアの書き込みにおいて、オペレーティング システムのキャッシュとファイル システムのオンディスク キャッシュの両方を使用できる。もっとも高速なポリシーだが、信頼性はもっとも劣る。他のポリシーに比べて 100 倍以上高速だが、停電やオペレーティング システムの障害によってメッセージが消失したり重複したりするおそれがある。
Cache-Flush	デフォルトのポリシー。すべての書き込みがディスクにフラッシュされるまでトランザクションは完了しない。このポリシーは信頼性とスケーラビリティが高く、同時に処理できるユーザ数も増える。
Direct-Write	ファイル ストアの書き込みが、直接ディスクに書き込まれる。このポリシーは、Sun Solaris および Windows システムでサポートされている。サポートされていないプラットフォームで Direct-Write ポリシーを設定した場合、ファイル ストアは自動的に Cache-Flush ポリシーを代わりに使用する。 Direct-Write ポリシーの信頼性とパフォーマンスは、直接書き込みに関するプラットフォームのオンディスク キャッシュの用法によって異なる。 たとえば、UNIX システムでは直接書き込みにオンディスク キャッシュを使用しないが、Windows システムでは通常使用する。 このポリシーでオンディスク キャッシュ (利用可能な場合) を使用する際の良い点と悪い点は以下のとおり。 オンディスク キャッシュを有効にすると、Cache-Flush ポリシーに比べて 2 〜 5 倍高速になる。ただし、非常に高いスケーラビリティが要求される場合は、多少遅くなるおそれがある。 オンディスク キャッシュを無効にすると、1 対多の場合は Cache-Flush ポリシーより速いが、それ以外の場合は Cache-Flush ポリシーより遅くなる。 Direct-Write ポリシーでは、オンディスク キャッシュを有効にするとスケーラビリティが向上し、無効にすると向上しない(Sun Solaris では直接書き込みのオンディスク キャッシュを有効にできないことに注意)。

 

警告: Sun Solaris とは異なり、Windows 上で Direct-Write ポリシーを使用する場合、トランザクション データはオンディスク キャッシュに残され、すぐにはディスクに書き込まれません。この場合、停電などによってオンディスク キャッシュのデータが消えてメッセージが消失したり重複したりするおそれがあり、トランザクションとしては安全とはいえません。Windows で Direct-Write の信頼性を高めるには、ディスクの書き込みキャッシュをすべて無効にするか、バッテリー バックアップのあるキャッシュを使用します。

Windows でハードディスクのオンディスク キャッシュを無効にするには、[スタート｜設定｜コントロール パネル｜システム] を選択し、[ハードウェア] タブで [デバイス マネージャ] ボタンをクリックして [ディスク ドライブ] アイコンをダブルクリックします。次に、ドライブの名前をダブルクリックし、[ディスクのプロパティ] タブの [書き込みキャッシュを有効にする] チェック ボックスのチェックをはずします。ただし、この値を変更できないファイル システムもあります (たとえば、信頼性のあるキャッシュを備えた RAID システム)。

ポリシー設定の比較

以下の表では、信頼性、パフォーマンス、およびスケーラビリティに関して、同期書き込みポリシーを比較しています。以下のキーポイントを使用して、同期書き込みポリシーの設定に基づいて予想される結果を解釈してください。

• ディスク キャッシュ (オン/オフ) : オンディスクの書き込みキャッシュが有効または無効のどちらか。

• 1-m のパフォーマンス : 非常に少ないクライアント。

• m-m のパフォーマンス : 多数のクライアント。

• M-M のパフォーマンス : 多数の同時クライアント。

• 信頼性 (低/高) : 「かならず 1 回」の (トランザクション) メッセージには高い信頼性が必要です。

  表9-2 相対的なパフォーマンス (同じカラム内で比較)

  ポリシー	ディスク キャッシュ	1-m のパフォーマンス	m-m のパフォーマンス	M-M のパフォーマンス	信頼性
  Disabled	オン	****	****	****	低 (OS のキャッシュによる)
  	オフ	****	****	****	低
  Cache-Flush	オン	*	**	***	高
  	オフ	*	**	***	高
  Direct-Write	オン	**	***	**	中 (信頼性の高いディスク キャッシュの場合は高)
  	オフ	**	*	*	高

  
   

  表9-3 相対的なスケーラビリティ (同じ行内で比較)

  ポリシー	ディスク キャッシュ	1-m のパフォーマンス	m-m のパフォーマンス	M-M のパフォーマンス
  Disabled	オン	****	****	****
  	オフ	****	****	****
  Cache-Flush	オン	*	**	***
  	オフ	*	**	***
  Direct-Write	オン	*	**	***
  	オフ	*	*	*

  
   

メッセージ ページングのコンフィグレーション

メッセージ ページング機能を使用すると、メッセージ負荷のピーク時に仮想メモリを解放できます。この機能は、大きなメッセージ空間を必要とするアプリケーションには非常に有効です。

JMS メッセージ ページングでは、永続メッセージおよび非永続メッセージの両方においてメモリを節約できます。永続メッセージのデータはメモリにキャッシュされますが、それでもメモリを節約する効果はあります。ページングされた永続メッセージは、通常のバッキング ストア (ファイルまたはデータベース) に書き込まれます。ページングされた非永続メッセージは、JMS サーバのメッセージ ページング ストアに書き込まれます。これらは別々にコンフィグレーションできます。

メッセージをページから取り出しても、これに使用されていたすべてのメモリが解放されるわけではありません。メッセージのヘッダとプロパティはメモリに残され、検索、ソート、およびフィルタリングに使用されます。

注意: トランザクション セッションで送信されるメッセージは、セッションがコミットされた後にのみページングできます。 その前には、メッセージはメモリにのみ保持されます。したがって、Java 仮想マシン (JVM) のヒープ サイズは、コミットされるまですべてのアクティブ セッションからのクライアント負荷の予想される最大量に対応できるように適切に調整する必要があります。 ヒープ サイズのチューニングの詳細については、『BEA WebLogic Server パフォーマンス チューニング ガイド』の「Java 仮想マシン (JVM) のチューニング」を参照してください。

ページングのコンフィグレーション

ページングがコンフィグレーションされていないか有効になっていない場合は、すべてのメッセージ (永続的なメッセージを含む) がメモリに保持されます。Administration Console を使用して、新規または既存の JMS サーバまたはその送り先に対してページングをコンフィグレーションできます。[JMS｜サーバ] ノードの属性を使用して、JMS サーバのページング ストアを指定したり、バイトまたはメッセージ ページングを有効にしたり、ページングを開始および停止するバイト/メッセージの最大および最小しきい値をコンフィグレーションしたりすることができます。

同様に、[送り先] ノードの属性を使用して、JMS サーバでコンフィグレーションされているすべてのトピックおよびキューのバイト/メッセージ ページングをコンフィグレーションできます。送り先は、JMS サーバ用にコンフィグレーションされているページング ストアを使用します。

また、JMS テンプレートを使用して複数の送り先をコンフィグレーションする場合、[テンプレート] ノードの属性を使用して、すべての送り先のページングをすばやくコンフィグレーションできます。特定の送り先に関してテンプレートのページング コンフィグレーションをオーバーライドする場合、どの送り先に対してもページングを有効または無効にできます。

新規の JMS サーバ、テンプレート、および送り先 (トピックまたはキュー) のコンフィグレーション手順については、Administration Console オンライン ヘルプの「JMS サーバ」、「JMS 送り先」、および「JMS テンプレート」を参照してください。

注意: パフォーマンスをチューニングするために、ページングのしきい値をいつでも有効な値に変更できます。 ただし、ページを有効にすると、バイトまたはメッセージしきい値を -1 にリセットしてページングを動的に無効にすることはできません。 ページングの発生を防止するには、バイト/メッセージの最大しきい値を非常に大きな値 (最大値は 263 -1) に設定して、ページングが開始されないようにします。

JMS サーバのページング ストアのコンフィグレーション

ページング ストアは、JMS サーバごとに必要です。各 JMS サーバおよびその送り先への非永続メッセージは、この専用のページ ストアを使用してページングされます。JMS JDBC ストアではなく、JMS ファイル ストアを使用することをお勧めします。JDBC ストアは、特にメリットがない上、性能も劣るためです。

新しいページング ストアをコンフィグレーションするには、次の手順に従います。

1. Administration Console を起動します。

2. [JMS｜ストア] ノードをクリックします。すべての JMS ストアが右ペインに表示されます。

3. [新しい JMSFile Store のコンフィグレーション] テキスト リンクをクリックします。新しいファイル ストアのコンフィグレーションに関連するタブが右ペインに表示されます。

4. 属性フィールドに値を入力します。

5. [作成] をクリックして、[名前] フィールドで指定した名前のファイル ストア インスタンスを作成します。新しいインスタンスが左ペインの [JMS｜ストア] ノード下に追加されます。

6. ドメインに複数の JMS サーバがある場合、サーバ インスタンスごとに手順 3 〜 5 を繰り返します。

JMS サーバのページングのコンフィグレーション

既存の JMS サーバでページングをコンフィグレーションして有効にするには、次の手順に従います。

1. [JMS｜サーバ] ノードをクリックします。ドメインに定義されているすべてのサーバが右ペインに表示されます。

2. ページングをコンフィグレーションするサーバをクリックします。サーバのコンフィグレーションに関連するタブが右ペインに表示されます。

3. [一般] タブの [ページング ストア] リスト ボックスで、ページングしたメッセージを格納するためのストアを選択します。[適用] をクリックして変更を保存します。

   ページング ストアのコンフィグレーション手順については、JMS サーバのページング ストアのコンフィグレーションを参照してください。

4. [しきい値と割当] タブで、バイト ページングをコンフィグレーションします。

   • [バイト ページングを有効化] チェック ボックスを選択します。

   • [最大バイトしきい値] フィールドで、バイト ページングを開始する基準値となる JMS サーバのバイト数を入力します。

   • [最小バイトしきい値] フィールドで、バイト ページングを停止する基準値となる JMS サーバのバイト数を入力します。

5. [しきい値と割当] タブで、メッセージ ページングをコンフィグレーションします。

   • [メッセージ ページングを有効化] チェック ボックスを選択します。

   • [最大メッセージしきい値] フィールドで、メッセージ ページングを開始する基準値となる JMS サーバのメッセージ数を入力します。

   • [最小メッセージしきい値] フィールドで、メッセージ ページングを停止する基準値となる JMS サーバのメッセージ数を入力します。

6. [適用] をクリックして、新しいバイト ページング値とメッセージ ページング値を保存します。

7. ドメインの JMS サーバのページングをさらにコンフィグレーションするには、手順 2 〜 6 を繰り返します。

   注意: 各 JMS サーバは、それぞれ独自の永続ストレージを使用する必要があります。

8. JMS サーバのページングをコンフィグレーションしたら、次のいずれかの操作を行います。

   • JMS サーバの送り先のページングをコンフィグレーションしない場合、WebLogic Server を再起動してページングを有効にします。

   • サーバの送り先のページングをコンフィグレーションする場合、JMS テンプレートのページングのコンフィグレーションまたは 送り先のページングのコンフィグレーションの手順に従います。

JMS テンプレートのページングのコンフィグレーション

JMS テンプレートを使用することによって、似た属性設定を持つ複数の送り先 (トピックまたはキュー) を効率的に定義できます。送り先用のテンプレートでページングをコンフィグレーションするには、次の手順に従います。

1. 左ペインの [JMS] ノードをクリックします。

2. [テンプレート] ノードをクリックします。ドメインに定義されているすべてのテンプレートが右ペインに表示されます。

3. ページングをコンフィグレーションするテンプレートをクリックします。テンプレートのコンフィグレーションに関連するタブが右ペインに表示されます。

4. [しきい値と割当] タブで、バイト ページングをコンフィグレーションします。

   • [バイト ページングを有効化] チェック ボックスを選択します。

   • [最大バイトしきい値] フィールドで、バイト ページングを開始する基準値となる JMS サーバのバイト数を入力します。

   • [最小バイトしきい値] フィールドで、バイト ページングを停止する基準値となる JMS サーバのバイト数を入力します。

5. [しきい値と割当] タブで、メッセージ ページングをコンフィグレーションします。

   • [メッセージ ページングを有効化] チェック ボックスを選択します。

   • [最大メッセージしきい値] フィールドで、メッセージ ページングを開始する基準値となる JMS サーバのメッセージ数を入力します。

   • [最小メッセージしきい値] フィールドで、メッセージ ページングを停止する基準値となる JMS サーバのメッセージ数を入力します。

6. [適用] をクリックして、新しいバイト ページング値とメッセージ ページング値を保存します。

7. JMS テンプレートのページングをさらにコンフィグレーションするには、手順 3 〜 6 を繰り返します。

8. ページングに関してすべての JMS テンプレートをコンフィグレーションしたら、WebLogic Server を再起動してページングを有効にします。

送り先のページングのコンフィグレーション

JMS テンプレートを使用しないで送り先のページングをコンフィグレーションする場合、以下の手順に従います。

1. [JMS｜サーバ] で、ページングがコンフィグレーションされているサーバ インスタンスを展開します。

2. [送り先] ノードをクリックします。サーバのトピックおよびキューが右ペインにすべて表示されます。

3. ページングをコンフィグレーションするトピックまたはキューをクリックします。トピックまたはキューのコンフィグレーションに関連するタブが右ペインに表示されます。

4. [しきい値と割当] タブで、バイト ページングをコンフィグレーションします。

   • [バイト ページングを有効化] チェック ボックスを選択します。

   • [最大バイトしきい値] フィールドで、バイト ページングを開始する基準値となる JMS サーバのバイト数を入力します。

   • [最小バイトしきい値] フィールドで、バイト ページングを停止する基準値となる JMS サーバのバイト数を入力します。

5. [しきい値と割当] タブで、メッセージ ページングをコンフィグレーションします。

   • [メッセージ ページングを有効化] チェック ボックスを選択します。

   • [最大メッセージしきい値] フィールドで、メッセージ ページングを開始する基準値となる JMS サーバのメッセージ数を入力します。

   • [最小メッセージしきい値] フィールドで、メッセージ ページングを停止する基準値となる JMS サーバのメッセージ数を入力します。

6. [適用] をクリックして、新しいバイト ページング値とメッセージ ページング値を保存します。

7. JMS 送り先のページングをさらにコンフィグレーションするには、手順 3 〜 6 を繰り返します。

8. ページングに関してすべての送り先をコンフィグレーションしたら、WebLogic Server を再起動してページングを有効にします。

注意: JMS テンプレートを使用して送り先をコンフィグレーションした場合、送り先のバイト/メッセージ ページングを明示的にコンフィグレーションすると、テンプレートのコンフィグレーションはオーバーライドされます。 詳細については、JMS テンプレートのページングをオーバーライドする送り先のコンフィグレーションおよびJMS のコンフィグレーションを参照してください。

JMS テンプレートのページングをオーバーライドする送り先のコンフィグレーション

テンプレートの設定をオーバーライドして特定の送り先のページングを有効または無効にする場合、次の手順に従います。

1. [JMS｜サーバ] で、ページングがコンフィグレーションされているサーバ インスタンスを展開します。

2. [送り先] ノードをクリックします。サーバのトピックおよびキューが右ペインにすべて表示されます。

3. ページングをコンフィグレーションするトピックまたはキューをクリックします。サーバ インスタンスに関連付けられたトピックまたはキューが右ペインに表示されます。

4. [しきい値と割当] タブで、JMS テンプレートをオーバーライドする方法に応じて送り先の [バイト ページングを有効化] または [メッセージ ページングを有効化] 属性をコンフィグレーションします。

   • 送り先のページングを無効にするには、[バイト ページングを有効化] または [メッセージ ページングを有効化] リスト ボックスで [False] を選択します。

   • 送り先のページングを有効にするには、[バイト ページングを有効化] または [メッセージ ページングを有効化] リスト ボックスで [True] を選択します。

5. [適用] をクリックして、新しいバイト ページング値とメッセージ ページング値を保存します。

6. 同じサーバ インスタンスの JMS 送り先のページングをさらにコンフィグレーションするには、手順 2 〜 5 を繰り返します。

7. ページングに関してすべての送り先をコンフィグレーションしたら、WebLogic Server を再起動してページングを有効にします。

JMS のページング属性

以降の節では、WebLogic Server JMS で使用可能なページング属性について簡単に説明します。

JMS サーバのページング属性

表 9-4 では、JMS サーバでのページングをコンフィグレーションするときに定義するページング属性について説明します。 JMS サーバの属性の詳細、および属性の有効な値とデフォルト値については、Administration Console オンライン ヘルプの「JMS サーバ」を参照してください。

表9-4 JMS サーバの属性

属性	説明
[バイト ページングを有効化]	[バイト ページングを有効化] チェック ボックスを選択しない場合 (False)、サーバのバイト ページングは明示的に無効になる。 [バイト ページングを有効化] チェック ボックスを選択し (True)、ページング ストアがコンフィグレーションされており、[最小バイトしきい値] および [最大バイトしきい値] 属性が -1 より大きい場合、サーバのバイト ページングは有効になる。 [最小バイトしきい値] または [最大バイトしきい値] 属性のいずれかが定義されていない場合、または -1 に設定されている場合、[バイト ページングを有効化] が選択されていても (True)、サーバのバイト ページングは暗黙的に無効になる。
[メッセージ ページングを有効化]	[メッセージ ページングを有効化] チェック ボックスを選択しない場合 (False)、サーバのメッセージ ページングは明示的に無効になる。 [メッセージ ページングを有効化] チェック ボックスを選択し (True)、ページング ストアがコンフィグレーションされており、[最小メッセージしきい値] および [最大メッセージしきい値] 属性が -1 より大きい場合、サーバのメッセージ ページングは有効になる。 [最小メッセージしきい値] または [最大メッセージしきい値] 属性のいずれかが定義されていない場合、または -1 に設定されている場合、[メッセージ ページングを有効化] が選択されていても (True)、サーバのメッセージ ページングは暗黙的に無効になる。
[ページング ストア]	非永続メッセージをページングする永続ストレージの名前。ページング ストアは、永続メッセージまたは恒久サブスクライバ用と同じストアであってはならない。 2 つの JMS サーバは同じページング ストアを使用することができないので、サーバごとに固有のページング ストアをコンフィグレーションする必要がある。

 

JMS テンプレートのページング属性

表 9-5 では、JMS テンプレートで送り先のページングをコンフィグレーションするときに定義するページング属性について説明します。 JMS テンプレートの属性の詳細、および属性の有効な値とデフォルト値については、Administration Console オンライン ヘルプの「JMS テンプレート」を参照してください。

表9-5 JMS テンプレートの属性

属性	説明
[バイト ページングを有効化]	[バイト ページングを有効化] チェック ボックスを選択しない場合 (Flase)、送り先レベルのバイト ページングは、送り先の設定でテンプレートをオーバーライドしない限り、JMS テンプレートの送り先に関して無効になる。 [バイト ページングを有効化] チェック ボックスを選択し (True)、JMS サーバのページング ストアがコンフィグレーションされており、[最小バイトしきい値] および [最大バイトしきい値] 属性が -1 より大きい場合、送り先レベルのバイト ページングは、送り先の設定でテンプレートをオーバーライドしない限り、JMS テンプレートの送り先に関して有効になる。 JMS テンプレート Mbean に値が定義されてない場合、False がデフォルト値となるので、JMS テンプレートの送り先に関するバイト ページングは無効になる。
[メッセージ ページングを有効化]	[メッセージ ページングを有効化] チェック ボックスを選択しない場合 (False)、送り先レベルのメッセージ ページングは、送り先の設定でテンプレートをオーバーライドしない限り、テンプレートの送り先に関して無効になる。 [メッセージ ページングを有効化] チェック ボックスを選択し (True)、JMS サーバのページング ストアがコンフィグレーションされており、[最小バイトしきい値] および [最大バイトしきい値] 属性が -1 より大きい場合、送り先レベルのメッセージ ページングは、送り先の設定でテンプレートをオーバーライドしない限り、テンプレートの送り先に関して有効になる。 JMS テンプレート Mbean に値が定義されてない場合、False がデフォルト値となるので、JMS テンプレートの送り先に関するメッセージ ページングは無効になる。

 

JMS 送り先のページング属性

表 9-6 では、送り先に関するページングをコンフィグレーションするときに定義するページング属性について説明します。 JMS 送り先の属性の詳細、および属性の有効な値とデフォルト値については、Administration Console オンライン ヘルプの「JMS の送り先」を参照してください。

表9-6 JMS の送り先の属性

属性	説明
[バイト ページングを有効化]	[バイト ページングを有効化] を False に設定すると、送り先レベルのバイト ページングはその送り先に関して無効になる。 [バイト ページングを有効化] を True に設定し、JMS サーバのページング ストアがコンフィグレーションされており、[最小バイトしきい値] および [最大バイトしきい値] 属性が -1 より大きい場合、送り先レベルのバイト ページングはその送り先に関して有効になる。 [バイト ページングを有効化] をデフォルト設定にすると、この値はテンプレートの値を継承する (テンプレートが指定されている場合)。送り先のテンプレートがコンフィグレーションされていない場合、デフォルト値は false と同じになる。
[メッセージ ページングを有効化]	[メッセージ ページングを有効化] を False に設定すると、送り先レベルのメッセージ ページングはその送り先に関して無効になる。 [メッセージ ページングを有効化] を True に設定し、JMS サーバのページング ストアがコンフィグレーションされており、[最小バイトしきい値] および [最大バイトしきい値] 属性が -1 より大きい場合、送り先レベルのメッセージ ページングはその送り先に関して有効になる。 [メッセージ ページングを有効化] をデフォルト設定にすると、この値はテンプレートの値を継承する (テンプレートが指定されている場合)。送り先のテンプレートがコンフィグレーションされていない場合、デフォルト値は false と同じになる。

 

注意: サーバのページングが有効で、送り先レベルのページングが指定した送り先に関して無効になっている場合、サーバのページングが開始されると、送り先のメッセージはページングされます。ただし、送り先レベルのページングが指定した送り先に関して無効になっている場合、送り先のメッセージ数がその送り先の最大しきい値を超えても、メッセージはページングされません。

ページングのしきい値属性

表 9-7 では、JMS サーバ、テンプレート、および送り先で使用可能なバイトおよびメッセージ ページングのしきい値について簡単に説明します。 JMS サーバ、テンプレート、および送り先の属性の詳細と、属性の有効な値およびデフォルト値については、Administration Console オンライン ヘルプの「JMS サーバ」、「JMS の送り先」、および「JMS テンプレート」を参照してください。

表9-7 ページングのしきい値属性

属性	説明
[最大バイトしきい値]	バイト数がこのしきい値を超えるとページングが開始される。
[最小バイトしきい値]	バイト数がこのしきい値を下回るとページングが停止される。
[最大メッセージしきい値]	メッセージ数がこのしきい値を超えるとページングが開始される。
[最小メッセージしきい値]	メッセージ数がこのしきい値を下回るとページングが停止される。

 

しきい値は、サーバ、テンプレート、および送り先に対して次のように定義します。

• 最大または最小バイトしきい値を定義しない場合 (または -1 を定義した場合)、バイト数はページングを開始および停止するタイミングの決定に使用されない。

• 最大または最小メッセージしきい値を定義しない場合 (または -1 を定義した場合)、メッセージ数はページングを開始および停止するタイミングの決定に使用されない。

• サーバまたはテンプレート/送り先に関しては、ページングを有効にするために [バイト ページングを有効化]/[メッセージ ページングを有効化] 属性を True に設定する必要がある。しきい値を設定し、ページングが有効になっていない場合、しきい値条件に達した時点でメッセージがサーバのログに記録されます。

メッセージのフロー制御の確立

WebLogic JMS のフロー制御機能を使うと、メッセージ プロデューサが過負荷になっていると判断したときに、JMS サーバまたは送り先で、メッセージ プロデューサの処理速度を低下させることができます。具体的には、JMS サーバや送り先で、指定のバイト数またはメッセージ数のしきい値を超えた場合に対処機能が作動し、メッセージ フロー (1 秒当たりのメッセージ数) を制限するようプロデューサに指示が出されます。

プロデューサでは、JMS 接続ファクトリを通じてプロデューサ用にコンフィグレーションされた一連のフロー制御属性に基づき、プロダクション率を制限します。プロデューサは、指定した最大フローのメッセージ数から開始して、所定の間隔ごとに (たとえば、60 秒間、10 秒ごとに)、サーバや送り先がまだ対処機能を作動させたままであるかどうかを評価します。各間隔ごとに、サーバや送り先で対処機能が作動したままであれば、プロデューサは、所定のフロー最小値まで、プロダクション率を低下させます。

プロデューサで処理速度が低下するにつれ、しきい値条件は徐々に補正されます。これはサーバや送り先の対処機能が解除されるまで行われます。この時点で、プロデューサはプロダクション率を上げることができるようになりますが、必ずしも最大限まで上げる必要はありません。実際には、メッセージ フローは、所定の最大フローに達してフロー制御の対象でなくなる時点までは、(サーバや送り先が対処機能を解除していても) 引き続き制御されます。

フロー制御のコンフィグレーション

プロデューサは、セッションから一連のフロー制御属性を受信します。セッションは接続から、接続は接続ファクトリから、この属性を受信します。JMS 接続ファクトリでのフロー制御属性のコンフィグレーションは、Administration Console を通じて行います。

これらの属性により、プロデューサはメッセージ フローを調整できます。具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。最小値側および最大値側への移行は、移行率を指定する 2 つの追加属性によって定義されます。また、最小値側および最大値側への移行の必要性は、コンフィグレーションされた間隔ごとに評価されます。

接続ファクトリでのメッセージ フロー制御をコンフィグレーションするには、以下の手順に従います。

1. [JMS] ノードを展開します。

2. [接続ファクトリ] ノードをクリックします。右ペインに [JMS 接続ファクトリ] テーブルが表示され、ドメインで定義された接続ファクトリがすべて示されます。

3. メッセージ フロー制御を確立する接続ファクトリをクリックします。右ペインにダイアログが表示され、接続ファクトリの変更に関連するタブが示されます。

4. [フロー制御] タブで、次の表で説明する属性を定義します。

   表9-8 フロー制御属性

   属性	説明
   [フロー制御を有効化]	プロデューサが JMS サーバによってフロー制御可能かどうかを決定する。
   [最大フロー]	しきい値の条件に達したプロデューサに対する秒当たりの最大メッセージ数。 しきい値の条件に達したときにプロデューサがフローを制御している場合、そのプロデューサの初期フロー制限が FlowMaximum に設定される。しきい値の条件に達したときにプロデューサが既にフローを制御している場合 (フロー制限は FlowMaximum 未満)、プロデューサは次にフローが評価されるまで現在のフロー制限で処理を継続する。 いったん、しきい値条件への抵触を回避してからは、プロデューサはフロー限度を無視できなくなる。このフロー制限が FlowMaximum 未満の場合、プロデューサはフローが評価されるたびにそのフローを徐々に FlowMaximum まで増やす必要がある。プロデューサが FlowMaximum に達すると、そのフロー制限を無視し、そのフローを制限せずに送信できる。
   [最小フロー]	しきい値の条件に達したプロデューサに対する秒当たりの最小メッセージ数。これは、プロデューサのフロー制御の下限値。つまり、WebLogic JMS は、フロー制限が FlowMinimum に達したプロデューサの処理速度はそれ以上落とさない。
   [フロー間隔]	プロデューサが FlowMaximum のメッセージ数から FlowMinimum に、またはその反対にフローを調整するときの調整期間 (単位は秒)。
   [フロー ステップ]	プロデューサがフローを [最小フロー] のメッセージ数から [最大フロー] のメッセージ数に、または [最大フロー] のメッセージ数から [最小フロー] のメッセージ数に、調整する場合に使用されるステップ数。フロー間隔の調整期間は、フローステップ数に分割される (たとえば 60 秒を 6 ステップで割ると 1 ステップ 10 秒となる)。 また、FlowMaximum と FlowMinimum の差をステップに分割することにより、移動 (調整率) が計算される。各フロー ステップでは、次のように現在の条件に基づいて必要に応じてフローが上方または下方に調整される。 下方移動 (減衰) は指定した期間 (フロー間隔) および指定したステップ数に対し幾何級数的 (たとえば、100、50、25、12.5)。 上方移動は線形。差は単純にステップ数で除算される。

   
    

5. [適用] をクリックして、新しい属性値を保存します。

他の接続ファクトリ属性の詳細、および属性の有効な値とデフォルト値については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ」を参照してください。

フロー制御のしきい値

バイト数やメッセージ数のしきい値のコンフィグレーションに使用される属性は、JMS サーバおよび JMS 送り先の一部として定義されます。 表 9-9 では、これらのしきい値がどのように JMS サーバや JMS 送り先に対するフロー制御を開始および停止するのかを示します。

表9-9 フロー制御しきい値属性

属性	説明
[最大バイトしきい値] または [最大メッセージしきい値]	バイト数やメッセージ数がこのしきい値を超えると、JMS サーバまたは JMS 送り先で対処機能が作動し、プロデューサに対してメッセージ フローを制限するよう指示が行われる。
[最小バイトしきい値] または [最小メッセージしきい値]	バイト数やメッセージ数がこのしきい値を下回る場合、JMS サーバまたは JMS 送り先で対処機能が解除され、プロデューサに対してメッセージ フローを増やし始めるよう指示が行われる。 フロー制御は、メッセージの最大フローを下回っているプロデューサについては、引き続き有効である。プロデューサは、最大フローに到達してフロー制御が行われなくなるまで、プロデュース率を上げ続けることができる。

 

JMS サーバおよび JMS 送り先の属性の詳細と、属性の有効な値およびデフォルト値については、Administration Console オンライン ヘルプの「JMS サーバ」、および「JMS の送り先」を参照してください。

分散送り先のチューニング

以降の節では、JMS 接続ファクトリに対するロード バランシングとサーバ アフィニティの属性をコンフィグレーションすることで分散送り先をチューニングする方法について説明します。 分散送り先のコンフィグレーションの詳細については、分散送り先のコンフィグレーションを参照してください。

分散送り先のメッセージ ロード バランシングのコンフィグレーション

[JMS Connection Factory｜コンフィグレーション｜一般] タブの [ロード バランスを有効化] 属性では、接続ファクトリを通じて作成された匿名でないプロデューサが、呼び出しごとにロード バランシングされるかどうかを定義します。分散送り先を使用して、複数の物理的送り先にまたがってプロデューサおよびコンシューマを分散またはバランシングするが、メッセージが生成されるたびにロード バランシングの決定を行いたくないアプリケーションでは、[ロード バランスを有効化] 属性をオフにできます。

分散送り先でメッセージング負荷が公正に分散されるようにするために、プロデューサで使用される最初の物理的送り先 (キューまたはトピック) は必ず、分散送り先メンバーの中から無作為に選択されます。

接続ファクトリでのロード バランシングをコンフィグレーションするには、以下の手順に従います。

1. [JMS] ノードを展開します。

2. [接続ファクトリ] ノードをクリックします。右ペインに [JMS 接続ファクトリ] テーブルが表示され、ドメインで定義された接続ファクトリがすべて示されます。

3. メッセージのロード バランシングを確立する接続ファクトリをクリックします。右ペインにダイアログが表示され、接続ファクトリの変更に関連するタブが示されます。

4. [一般] タブで [ロード バランスを有効化] 属性を定義します。

   • [ロード バランスを有効化] = True
     Queue.sender.send() メソッドの場合、匿名でないプロデューサは呼び出しのたびに分散キュー メンバーでロード バランシングされます。
     
     TopicPublish.publish() メソッドの場合、匿名でないプロデューサはロード バランス有効化の設定に関係なく呼び出しのたびに常に同じ物理的トピックに固定されます。

   • [ロード バランスを有効化] = False
     プロデューサは、失敗するまで同じ物理的送り先に対して生成を行います。失敗すると、新しい物理的送り先が選択されます。

5. [適用] をクリックして変更を保存します。

   注意: 実装によっては、[サーバ アフィニティを有効化] 属性の設定が、分散送り先のロード バランシング設定に影響することがあります。 詳細については、『WebLogic JMS プログラマーズ ガイド』の「[サーバ アフィニティを有効化] 属性を使用した場合の分散送り先のロード バランシングへの影響」を参照してください。

匿名プロデューサ (作成時に送り先を指定しないプロデューサ) は、送り先を切り替えるたびにロード バランシングされます。同じ送り先を使用し続けると、匿名でないプロデューサと同じ法則 (前述) が適用されます。

分散送り先のメンバー間でメッセージのロード バランシングがどのように行われるのかについては、『WebLogic JMS プログラマーズ ガイド』の「分散送り先におけるメッセージのロード バランシング」を参照してください。

分散送り先のサーバ アフィニティのコンフィグレーション

[JMS Connection Factory｜コンフィグレーション｜一般] タブの [サーバ アフィニティを有効化] 属性では、分散送り先の複数の物理的送り先にわたってコンシューマまたはプロデューサをロード バランシングしている WebLogic Server が、同じ WebLogic Server 上で実行されている他の物理的送り先にまたがるロード バランシングを最初に試みるかどうかを定義します。

注意: [サーバ アフィニティを有効化] 属性は、キュー ブラウザに影響を与えません。 したがって、分散キューで作成されたキュー ブラウザは、サーバ アフィニティが有効な場合でもリモートの分散キュー メンバーに固定することができます。

接続ファクトリでサーバ アフィニティを無効化するには、次の手順に従います。

1. [JMS] ノードを展開します。

2. [接続ファクトリ] ノードをクリックします。右ペインに [JMS 接続ファクトリ] テーブルが表示され、ドメインで定義された接続ファクトリがすべて示されます。

3. サーバ アフィニティを無効化する対象となる接続ファクトリをクリックします。右ペインにダイアログが表示され、接続ファクトリの変更に関連するタブが示されます。

4. [一般] タブで [サーバ アフィニティを有効化] 属性を定義します。

   • [サーバ アフィニティを有効化] = True
     分散送り先セット内の複数の物理的送り先の間でコンシューマまたはプロデューサのロード バランシングを行っている WebLogic Server インスタンスは、まず、同じ WebLogic Server で実行されている他の物理的送り先の間でロード バランシングを試みます。

   • [サーバ アフィニティを有効化] = False
     WebLogic Server インスタンスは、分散送り先セットの複数の物理的送り先の間でコンシューマまたはプロデューサをロード バランシングし、同じ WebLogic Server 上で実行されている他の物理的送り先は無視します。

5. [適用] をクリックして変更を保存します。

[サーバ アフィニティを有効化] の設定が分散送り先メンバー間でのロード バランシングにどのように影響するのかについては、『WebLogic JMS プログラマーズ ガイド』の「[サーバ アフィニティを有効化] 属性を使用した場合の分散送り先のロード バランシングへの影響」を参照してください。

 

---

分散送り先のコンフィグレーション

分散送り先とは、1 つの JNDI 名で呼び出される物理的送り先 (キューまたはトピック) のセットのことです。したがって、セットのメンバーが実際にはクラスタ内の複数のサーバに分散し、各メンバーが別々の JMS サーバに属していても、そのセットはクライアント側からは 1 つの論理的送り先として認識されます。

複数の物理的キューおよびトピックを分散送り先のメンバーとしてコンフィグレーションできるようにすることで、WebLogic JMS はクラスタ内の JMS 送り先の高可用性とロード バランシングをサポートします。 たとえば、サーバの障害などによって使用できない送り先メンバーがある場合は、セット内の他のメンバーにトラフィックがリダイレクトされます。

複数の物理的キューおよびトピックを分散送り先のメンバーとしてコンフィグレーションできるようにすることで、WebLogic JMS はクラスタ内の JMS 送り先の高可用性とロード バランシングをサポートします。 アプリケーションで分散送り先を使用する手順については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

分散送り先のコンフィグレーションのガイドライン

分散 JMS 送り先は、[サービス｜JMS｜分散送り先] ノードでコンフィグレーションできます。 コンフィグレーション プロセスがわかりやすいように、以下のシナリオに対応する手順に分けて説明しています。

• 物理的送り先を持たない WebLogic JMS の新しい実装、または、コンフィグレーション済みの送り先を分散送り先の一部にする必要のない WebLogic JMS の既存のコンフィグレーション。

  • 分散トピックの作成とメンバーの自動作成

  • 分散キューの作成とメンバーの自動作成

• 以前にコンフィグレーションした送り先を分散送り先セットのメンバーとして追加する必要がある WebLogic JMS の既存の実装。

  • 分散トピックの作成および既存の物理的トピックのメンバーとしての手動追加

  • 分散キューの作成および既存の物理キューのメンバーとしての手動追加

分散送り先のコンフィグレーションのベスト プラクティス

分散送り先アプリケーションの管理と開発を簡素化するために、参加している各 JMS サーバおよびそれに関連付けられた物理的な送り先に対して同じようなコンフィグレーションを使用することで、分散送り先をクラスタ全体に一貫性を持ってデプロイすることをお勧めします。 これには、JMS ストア、メッセージ ページング、エラー送り先、メッセージおよびバイト数の割り当て、接続ファクトリなどの一貫したコンフィグレーションが必要になります。 たとえば、永続的なメッセージングがコンフィグレーションされている場合は、各分散メンバーがキャパシティとパフォーマンスに関して同様の JMS ストアに関連付けられるようにする必要があります。

分散送り先メンバーに対してコンフィグレーションの一貫性を保持するための推奨方法は、JMS テンプレートを使用することです。JMS テンプレートは、それぞれの物理的な送り先に共通するすべてのカスタム コンフィグレーションを一元化する最も信頼性のある方法だからです。 Administration Console を使用してコンフィグレーションされた、新たに作成された分散送り先メンバーの場合は、それらのメンバーに対して自動的に作成される JMS テンプレートを使用します (JMS テンプレートの自動作成を参照)。 既存の物理的な送り先を表すように作成された分散送り先の場合は、それらの物理的な送り先に関連付けられた JMS テンプレートを使用します。JMS テンプレートが存在しない場合はコンフィグレーションしてください (JMS テンプレートのコンフィグレーションを参照)。

警告: アプリケーションで障害が発生する問題を回避するために、参加している各分散送り先メンバーに対して一貫性のあるセキュリティ パーミッションをコンフィグレーションする必要があります。 たとえば、分散送り先のあるメンバーに他のメンバーとは異なる送信制限があると、アプリケーションでその分散送り先への送信が場合によって許可されたり、禁止されたりするおそれがあります。

ロード バランシングとサーバ アフィニティのチューニング

分散送り先のコンフィグレーションをチューニングするためのデフォルトの [ロード バランスを有効化] および [サーバ アフィニティを有効化] 属性の値は、Administration Console を使って JMS 接続ファクトリで変更できます。 詳細については、分散送り先のメッセージ ロード バランシングのコンフィグレーションおよび分散送り先のサーバ アフィニティのコンフィグレーションを参照してください。

JMS テンプレートの自動作成

Administration Console で新しい分散トピック メンバーまたは分散キュー メンバーと共に分散送り先が作成されると、それらのメンバーのデフォルト属性値を使用して対応する JMS テンプレートが自動的に作成されます。 新しい JMS テンプレートは、[JMS テンプレート] ノードに分散送り先と同じ名前で表示されます。 分散送り先メンバーのしきい値や割当などの属性は、このテンプレートを使用してリセットできます。 JMS テンプレートの使用の詳細については、JMS テンプレートのコンフィグレーションを参照してください。

JMS サーバを削除する場合の注意事項

クラスタ化されたコンフィグレーションでは、あらかじめ分散送り先コンフィグレーションから分散送り先メンバーを手動で削除せずに、そのメンバーをホストしている JMS サーバを割り当て解除または削除すると、コンフィグレーション ファイル (config.xml) が起動不能になる場合があります。 分散送り先メンバーを削除する手順については、JMS 分散キュー メンバーの削除およびJMS 分散トピック メンバーの削除を参照してください。

分散トピックの作成とメンバーの自動作成

分散トピックをコンフィグレーションし、WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにトピック メンバーを自動的に作成するには、以下の手順に従います。

1. [JMS｜分散送り先] ノードを展開します。

2. 右ペインで [新しい Distributed Topic のコンフィグレーション] リンクをクリックします。[コンフィグレーション] ダイアログに、新しい分散トピックのコンフィグレーションに関連するタブが表示されます。

3. 次の表に従って、[一般] タブの属性を定義します。

   表9-10 [一般] タブの分散トピック属性

   属性	説明
   [名前]	WebLogic Server ドメイン内で分散トピックをユニークに識別する。
   [JNDI 名]	分散トピックを JNDI ネームスペース内にバインドするために使用される名前を入力する。アプリケーションは、JNDI 名を使用して分散トピックをルックアップする。 JNDI 名を持たない分散トピックは、分散送り先の名前を javax.jms.TopicSession.createTopic() に渡すことで参照できる。
   [ロード バランス ポリシー]	プロデューサがどのようにメッセージを分散トピックのメンバー間に分散するかを定義する。 有効値は、分散送り先のメッセージ ロード バランシングのコンフィグレーションに定義される [ラウンドロビン] と [ランダム]。

   
    

4. [作成] をクリックして分散トピックを作成します。

5. [しきい値と割当] タブで、全分散トピック メンバーの以下の属性を定義します。

   • メッセージおよびバイト数のしきい値と割当 (最大数、最大しきい値と最小しきい値)。

   • バイト ページングやメッセージ ページングが分散トピックで有効化されているかどうか。

   これらの属性の詳細については、Administration Console オンライン ヘルプの「JMS 分散トピック] --> [コンフィグレーション] --> [しきい値と割当]」を参照してください。

6. [適用] をクリックして、新しい属性値を保存します。

7. [自動デプロイ] タブで、分散トピック メンバーを自動作成する WebLogic Server インスタンスを指定します。

8. [選択されたサーバ (および JMS サーバ) にメンバを作成する...] テキスト リンクをクリックします。以下のオプションのいずれかを選択するよう要求する自動デプロイ ダイアログが表示されます。

   • 分散トピックの対象とするクラスタを選択して ［次へ］ をクリックする。

     または

   • 個別のサーバまたはクラスタ内のサーバを選択できるように、[なし] オプションをそのまま使用してこのダイアログを無視する(この場合は、手順 10 に進む)。

9. クラスタを選択した場合は、以下の手順を実行して、クラスタ内の WebLogic Server インスタンスを選択します。

   1. クラスタのメンバーで、まだ分散トピックのホストではない WebLogic Server サーバが、すべてリストされ、デフォルトで選択されます。サーバ インスタンスが分散トピックのホストにならないようにするには、該当するチェック ボックスのチェックを解除します。

   2. [次へ] をクリックして次のダイアログに進みます。

   3. 分散トピック メンバーを作成するために選択した WebLogic Server で利用可能な JMS サーバを選択するには、手順 11 に進みます。

10. 手順 8 の [クラスタ] ダイアログで [なし] を選択した場合は、ドメイン内の単一の WebLogic Server インスタンスを選択します。

    1. リスト ボックスから、分散トピック メンバーを作成する個々のサーバを選択します。

    2. [次へ] をクリックして次のダイアログに進みます。

11. 選択した WebLogic Server インスタンス上にデプロイされており、まだ分散トピックのホストではない JMS サーバが、すべてリストされ、デフォルトで選択されます。JMS サーバが分散トピック メンバーのホストにならないようにするには、該当するチェック ボックスのチェックを解除します。

    選択した JMS サーバに既存の分散トピック メンバーがない場合は、各 JMS サーバに新しい JMSTopic が 1 つ作成され、分散トピックのメンバーとして追加されます。

12. [次へ] をクリックして、最後の [自動デプロイ] ダイアログに進みます。

13. [適用] をクリックして、[自動デプロイ] での選択を保存します。

14. [コンフィグレーション｜メンバ] タブをクリックして、新しい分散トピック用に自動作成されたトピック メンバーを表示します。

15. [JMS｜テンプレート] ノードを展開して、分散トピックと同じ名前で自動的に作成された JMS テンプレートを表示します。

分散トピックの作成および既存の物理的トピックのメンバーとしての手動追加

以前にコンフィグレーションした送り先を分散送り先セットのメンバーとして追加する必要がある WebLogic JMS の既存の実装で、分散トピックをコンフィグレーションして既存の物理トピックをメンバーとして手動で追加するには、以下の手順に従います。

1. [JMS｜分散送り先] ノードを展開します。

2. 右ペインで [新しい Distributed Topic のコンフィグレーション] リンクをクリックします。[コンフィグレーション] ダイアログに、新しい分散トピックのコンフィグレーションに関連するタブが表示されます。

3. 次の表に従って、[一般] タブの属性を定義します。

   表9-11 [一般] タブの分散トピック属性

   属性	説明
   [名前]	WebLogic Server ドメイン内で分散トピックをユニークに識別する。
   [JNDI 名]	分散トピックを JNDI ネームスペース内にバインドするために使用される名前を入力する。アプリケーションは、JNDI 名を使用して分散トピックをルックアップする。 JNDI 名を持たない分散トピックは、分散送り先の名前を javax.jms.TopicSession.createTopic() に渡すことで参照できる。
   [ロード バランス ポリシー]	プロデューサがどのようにメッセージを分散トピックのメンバー間に分散するかを定義する。 有効値は、分散送り先のメッセージ ロード バランシングのコンフィグレーションに定義される [ラウンドロビン] と [ランダム]。

   
    

4. [作成] をクリックして分散トピックを作成します。

5. [しきい値と割当] タブで、全分散トピック メンバーの以下の属性を定義します。

   • メッセージおよびバイト数のしきい値と割当 (最大数、最大しきい値と最小しきい値)。

   • バイト ページングやメッセージ ページングが分散トピックで有効化されているかどうか。

   分散トピック メンバーの基底の物理トピックに、既にしきい値と割当がコンフィグレーションされた JMS テンプレートが備わっている場合、これらの属性はそのトピック メンバーには適用されません。 これらの属性の詳細については、Administration Console オンライン ヘルプの「[JMS 分散トピック] --> [コンフィグレーション] --> [しきい値と割当]」を参照してください。

6. [適用] をクリックして、新しい属性値を保存します。

   注意: WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにトピック メンバーを自動的に作成する場合は、分散トピックの作成とメンバーの自動作成を参照してください。

7. [コンフィグレーション｜メンバ] タブで、既存の物理トピックのための分散トピック メンバーを作成します。

8. 右ペインで [新しい Distributed Topic Member のコンフィグレーション] リンクをクリックします。[コンフィグレーション] ダイアログに、新しい分散トピック メンバーのコンフィグレーションに関連するタブが表示されます。

9. 次の表に従って、[一般] タブの属性を定義します。

   表9-12 [一般] タブの分散トピック メンバー属性

   属性	説明
   [名前]	WebLogic Server ドメイン内で分散トピック メンバーをユニークに識別する。
   [JMS トピック]	分散トピック メンバーと関連する基底の物理トピックを選択する。
   [重み]	トピック メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のトピック メンバーとの比較で定義する。 ランダム分散ロード バランシング アルゴリズムは、物理的送り先に割り当てられた重みを使用して、一連の物理的送り先の重み付けされた分散を計算する。詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照。

   
    

10. [作成] をクリックして新しい分散トピック メンバーを作成します。新しいメンバーが [分散トピック] テーブルに追加されます。

11. 必要に応じて手順 8 〜 10 を繰り返し、トピック メンバーを分散トピックに追加し続けます。

分散キューの作成とメンバーの自動作成

分散キューをコンフィグレーションし、WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにキュー メンバーを自動的に作成するには、以下の手順に従います。

1. [JMS｜分散送り先] ノードを展開します。

2. 右ペインで [新しい Distributed Queue のコンフィグレーション] リンクをクリックします。[コンフィグレーション] ダイアログに、新しい分散キューのコンフィグレーションに関連するタブが表示されます。

3. 次の表に従って、[一般] タブの属性を定義します。

   表9-13 [一般] タブの分散キュー属性

   属性	説明
   [名前]	WebLogic Server ドメイン内で分散キューをユニークに識別する。
   [JNDI 名]	分散キューを JNDI ネームスペース内にバインドするために使用される名前を入力する。アプリケーションは、JNDI 名を使用して分散キューをルックアップする。 JNDI 名を持たない分散キューは、分散送り先名を javax.jms.QueueSession.createQueue() に渡すことによって参照できる。
   [ロード バランス ポリシー]	プロデューサがどのようにメッセージを分散キューのメンバー間に分散するかを定義する。 有効値は、分散送り先のメッセージ ロード バランシングのコンフィグレーションに定義される [ラウンドロビン] と [ランダム]。
   [転送の遅延]	メッセージを持つがコンシューマを持たない分散キュー メンバーが、コンシューマを持つ他のキューにメッセージを転送するまでに待機する時間を秒単位で定義する。

   
    

4. [作成] をクリックして分散キューを作成します。

5. [しきい値と割当] タブで、すべての分散キュー メンバーの以下の属性を定義します。

   • メッセージおよびバイト数のしきい値と割当 (最大数、最大しきい値と最小しきい値)。

   • バイト ページングやメッセージ ページングが分散キューで有効化されているかどうか。

   これらの属性の詳細については、Administration Console オンライン ヘルプの「JMS 分散トピック --> [コンフィグレーション] --> [しきい値と割当]」を参照してください。

6. [適用] をクリックして、新しい属性値を保存します。

7. [自動デプロイ] タブで、分散キュー メンバーを自動作成する WebLogic Server インスタンスを指定します。

8. [選択されたサーバ (および JMS サーバ) にメンバを作成する...] テキスト リンクをクリックします。以下のオプションのいずれかを選択するよう要求するダイアログが表示されます。

   • 分散キューの対象とするクラスタを選択して ［次へ］ をクリックする。

     または

   • クラスタ内にないサーバを個別に選択できるように、[なし] オプションをそのまま使用してこのダイアログを無視する(この場合は、手順 10 に進む)。

9. クラスタを選択した場合は、以下の手順を実行して、クラスタ内の WebLogic Server インスタンスを選択します。

   1. クラスタのメンバーで、まだ分散キューのホストではないサーバが、すべてリストされ、デフォルトで選択されます。サーバが分散キューのホストにならないようにするには、該当するチェック ボックスのチェックを解除します。

   2. [次へ] をクリックして次のダイアログに進みます。

   3. 分散キュー メンバーを作成するために選択した WebLogic Server で利用可能な JMS サーバを選択するには、手順 11 に進みます。

10. 手順 8 の [クラスタ] ダイアログで [なし] を選択した場合は、ドメイン内の単一の WebLogic Server インスタンスを選択します。

    1. リスト ボックスから、分散キュー メンバーを作成する個々のサーバを選択します。

    2. [次へ] をクリックして次のダイアログに進みます。

11. 選択した WebLogic Server 上にデプロイされており、まだ分散キューのホストではない JMS サーバが、すべてリストされ、デフォルトで選択されます。JMS サーバが分散キュー メンバーのホストにならないようにするには、該当するチェック ボックスのチェックを解除します。

    選択した JMS サーバに既存の分散キュー メンバーがない場合は、各 JMS サーバに新しい JMS キュー が 1 つ作成され、分散キューのメンバーとして追加されます。

12. [次へ] をクリックして、最後の [自動デプロイ] ダイアログに進みます。

13. [適用] をクリックして、[自動デプロイ] での選択を保存します。

14. [コンフィグレーション｜メンバ] タブをクリックして、新しい分散キュー用に自動作成されたキュー メンバーを表示します。

15. [JMS｜テンプレート] ノードを展開して、分散キューと同じ名前で自動的に作成された JMS テンプレートを表示します。

分散キューの作成および既存の物理キューのメンバーとしての手動追加

以前にコンフィグレーションした送り先を分散送り先セットのメンバーとして追加する必要があるWebLogic JMS の既存の実装で、分散キューをコンフィグレーションして既存の物理キューをメンバーとして手動で追加するには、以下の手順に従います。

1. [JMS｜分散送り先] ノードを展開します。

2. 右ペインで [新しい Distributed Queue のコンフィグレーション] リンクをクリックします。[コンフィグレーション] ダイアログに、新しい分散キューのコンフィグレーションに関連するタブが表示されます。

3. 次の表に従って、[一般] タブの属性を定義します。

   表9-14 [一般] タブの分散キュー属性

   属性	説明
   [名前]	WebLogic Server ドメイン内で分散キューをユニークに識別する。
   [JNDI 名]	分散キューを JNDI ネームスペース内にバインドするために使用される名前を入力する。アプリケーションは、JNDI 名を使用して分散キューをルックアップする。 JNDI 名を持たない分散キューは、分散送り先名を javax.jms.QueueSession.createQueue() に渡すことによって参照できる。
   [ロード バランス ポリシー]	プロデューサがどのようにメッセージを分散キューのメンバー間に分散するかを定義する。 有効値は、分散送り先のメッセージ ロード バランシングのコンフィグレーションに定義される [ラウンドロビン] と [ランダム]。
   [転送の遅延]	メッセージを持つがコンシューマを持たない分散キュー メンバーが、コンシューマを持つ他のキューにメッセージを転送するまでに待機する時間を秒単位で定義する。

   
    

4. [作成] をクリックして分散キューを作成します。

5. [しきい値と割当] タブで、すべての分散キュー メンバーの以下の属性を定義します。

   • メッセージおよびバイト数のしきい値と割当 (最大数、最大しきい値と最小しきい値)。

   • バイト ページングやメッセージ ページングが分散キューで有効化されているかどうか。

   分散キュー メンバーの基底の物理キューに、既にしきい値と割当がコンフィグレーションされた JMS テンプレートが備わっている場合、これらの属性はそのキュー メンバーには適用されません。 これらの属性の詳細については、Administration Console オンライン ヘルプの「[JMS 分散キュー] --> [コンフィグレーション] --> [しきい値と割当]」を参照してください。

6. [適用] をクリックして、新しい属性値を保存します。

   注意: WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにキュー メンバーを自動的に作成する場合は、分散キューの作成とメンバーの自動作成を参照してください。

7. [コンフィグレーション｜メンバ] タブをクリックして、分散キューのキュー メンバーを定義します。

8. 右ペインで [新しい Distributed Queue Member のコンフィグレーション] テキスト リンクをクリックします。[コンフィグレーション] ダイアログに、新しい分散キューのコンフィグレーションに関連するタブが表示されます。

9. 次の表に従って、[一般] タブの属性を定義します。

   表9-15 [一般] タブの分散キュー メンバー属性

   属性	説明
   [名前]	WebLogic Server ドメイン内で分散キュー メンバーをユニークに識別する。
   [JMS キュー]	分散キュー メンバーと関連する基底の物理キューを選択する。
   [重み]	キュー メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のキュー メンバーとの比較で定義する。 ランダム分散ロード バランシング アルゴリズムは、物理的送り先に割り当てられた重みを使用して、一連の物理的送り先の重み付けされた分散を計算する。 詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

   
    

10. [作成] をクリックして新しい分散キュー メンバーを作成します。新しいメンバーが [分散キュー] テーブルに追加されます。

11. 手順 8 〜 10 を繰り返して、分散キューにメンバーを追加し続けます。

JMS 分散キュー メンバーの作成

分散キューのメンバーとして既存の物理的キューを追加するには、次の手順に従います。

1. [JMS｜分散送り先] ノードを展開します。 [分散送り先] テーブルが右ペインに表示され、すべての分散キューおよびトピックが表示されます。

2. メンバーを追加する分散キューをクリックします。 [分散キュー] テーブルに、その分散キューに属しているすべての分散キュー メンバーが表示されます。

3. [新しい Distributed Queue Member のコンフィグレーション] テキスト リンクをクリックします。 ダイアログに、新しい分散キュー メンバーをコンフィグレーションするための [コンフィグレーション] タブが表示されます。

4. 分散キューのコンフィグレーション属性を定義します。

   • WebLogic Server ドメイン内で分散キュー メンバーをユニークに識別する。

   • 分散キュー メンバーと関連する基底の物理キューを選択する。

   • キュー メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のキュー メンバーとの比較で定義する。 分散送り先のロード バランシングの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

   分散キュー メンバーの属性の詳細については、Administration Console オンライン ヘルプの「[分散キュー メンバ] --> [コンフィグレーション]」を参照してください。

5. [作成] をクリックして、[名前] フィールドで指定した名前の分散キュー メンバーを作成します。 右ペインの [分散キュー メンバ] テーブルに、新しいメンバーが追加されます。

6. [適用] をクリックして、変更を保存します。

JMS 分散キュー メンバーの削除

分散キュー コンフィグレーションのメンバーを削除し、必要に応じてそのキュー メンバーの基底の物理的なキューも削除するには、次の手順に従います。 たとえば、あるキュー メンバーをホストしている JMS サーバを割り当て解除または削除する場合は、まず、分散送り先からそのメンバーを削除する必要があります。その JMS サーバを単純に割り当て解除または削除すると、コンフィグレーション ファイル (config.xml) が起動不能になる場合があります。

注意: 分散キュー全体を削除する必要がある場合は、分散送り先の削除の指示に従ってください。

1. [JMS｜分散送り先] ノードを展開します。 [分散送り先] テーブルが右ペインに表示され、すべての分散キューおよびトピックが表示されます。

2. メンバーを削除する分散キューをクリックします。 [分散キュー] テーブルに、その分散キューに属しているすべての分散キュー メンバーが表示されます。

3. 削除する分散キュー メンバーの行にある [削除] アイコンをクリックします。 削除要求の確認を求めるダイアログが表示されます。

4. 基底の物理的キューも一緒に削除する場合は、[Also Delete] チェック ボックスを選択します。

5. [削除] をクリックして、分散キュー メンバー (および選択した場合は基底の物理キュー) を削除します。

6. [分散キュー] テーブルが右ペインに再表示されます。 分散キュー メンバーが、[分散キュー] テーブルから削除されます。

JMS 分散トピック メンバーの作成

分散キューのメンバーとして既存の物理的キューを追加するには、次の手順に従います。

1. [JMS｜分散送り先] ノードを展開します。 [分散送り先] テーブルが右ペインに表示され、すべての分散キューおよびトピックが表示されます。

2. メンバーを追加する分散トピックをクリックします。 [分散トピック] テーブルに、その分散トピックに属しているすべての分散トピック メンバーが表示されます。

3. [新しい Distributed Topic Member のコンフィグレーション] テキスト リンクをクリックします。 ダイアログに、新しい分散トピック メンバーをコンフィグレーションするための [コンフィグレーション] タブが表示されます。

4. 分散トピックの全般的なコンフィグレーション属性を定義します。

   • WebLogic Server ドメイン内で分散トピック メンバーをユニークに識別する。

   • 分散トピック メンバーと関連する基底の物理トピックを選択する。

   • トピック メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のトピック メンバーとの比較で定義する。 分散送り先のロード バランシングの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

   分散トピック メンバーの属性の詳細については、Administration Console オンライン ヘルプの「[JMS 分散トピック メンバ] --> [コンフィグレーション]」を参照してください。

5. [作成] をクリックして、[名前] フィールドで指定した名前の分散トピック メンバーを作成します。 右ペインの [分散トピック] テーブルに、新しいメンバーが追加されます。

6. [適用] をクリックして、変更を保存します。

JMS 分散トピック メンバーの削除

分散トピックを削除し、必要に応じてメンバーの基底の物理トピックも削除するには、次の手順に従います。

注意: 分散トピック全体を削除する必要がある場合は、分散送り先の削除の指示に従ってください。

1. [JMS] ノードを展開します。

2. [分散送り先] ノードを展開します。 [分散送り先] テーブルが右ペインに表示され、すべての分散キューおよびトピックが表示されます。

3. メンバーを削除する分散トピックをクリックします。 [分散トピック] テーブルに、その分散トピックに属しているすべての分散トピック メンバーが表示されます。

4. 削除する分散トピック メンバーの行にある [削除] アイコンをクリックします。 削除要求の確認を求めるダイアログが表示されます。

5. 基底の物理的キューも一緒に削除する場合は、[Also Delete] チェック ボックスを選択します。

6. [削除] をクリックして、分散トピック メンバー (および選択した場合は基底の物理トピック) を削除します。

7. [分散トピック] テーブルが右ペインに再表示されます。 分散トピック メンバーが、[分散トピック] テーブルから削除されます。

分散送り先の削除

分散送り先全体を削除する場合は、次の手順で削除する必要があります。

1. 以下の節の説明に従って、分散キューまたは分散トピックのすべてのメンバーを削除します。

   • JMS 分散キュー メンバーの削除

   • JMS 分散トピック メンバーの削除

2. [JMS｜分散送り先] ノードを展開し、削除する分散送り先の隣のごみ箱アイコンをクリックして分散送り先それ自体を削除します。

   注意: 分散送り先は、そのメンバーがすべて適切に削除されている場合のみ削除できます。

3. 分散送り先と関連付けられている JMS テンプレートを削除できます。 ただし、そのテンプレートが他の JMS サーバまたは送り先で使用されていないようにしてください。 JMS テンプレートを削除するには、[JMS｜テンプレート] ノードを展開してから、削除する JMS テンプレートの行にあるごみ箱アイコンをクリックします。

分散送り先のモニタ

分散送り先をモニタする場合、そのトピックまたはキュー メンバーに対して自動的に作成されるプロキシ トピック メンバーまたはシステム サブスクリプションを参照できます。 詳細については、分散送り先のシステム サブスクリプションとプロキシ トピック メンバーのモニタを参照してください。

 

---

WebLogic Server の障害からの回復

以降の節では、サーバで障害が発生した場合に JMS アプリケーションを正常に終了させる方法、およびサーバで障害が発生した後に JMS データを移行する方法について説明します。

プログラミングの考慮事項

WebLogic Server の障害発生時に正常に終了するよう、JMS アプリケーションをプログラミングすることもできます。 次に例を示します。

WebLogic Server インスタンスの障害発生時の状態	対応
障害が発生した WebLogic Server インスタンスに接続していた。	JMSException が接続例外リスナに配信される。サーバを再起動または交換したらすぐに、アプリケーションを再起動する必要がある。
障害が発生した WebLogic Server インスタンスに接続していなかった。	サーバを再起動または交換したらすぐに、すべてを再確立する必要がある。
障害が発生した WebLogic Server インスタンスが JMS サーバの対象になっていた。	ConsumerClosedException がセッション例外リスナに配信される。失われたすべてのメッセージ コンシューマを再確立する必要がある。

 

新しいサーバへの JMS データの移行

WebLogic JMS では、WebLogic Server のコアに実装される移行フレームワークを使用します。これにより、WebLogic JMS は移行要求に正しく応答できるようになり、WebLogic JMS サーバのオンラインとオフラインの切り替えが順序立って行われるようになります。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への対応としての移行も含まれます。

いったん、正しくコンフィグレーションされると、JMS サーバとそのすべての送り先メンバーは、クラスタ内の別の WebLogic Server に移行できます。

新しくサーバを起動し、次の表に記載されたタスクのうち 1 つ以上を実行することで、障害が発生した WebLogic Server から JMS データを回復できます。

JMS アプリケーションで使用している機能	実行するタスク
永続的なメッセージング-JDBC ストア	障害が発生したサーバに JDBC データベース ストアが存在している場合は、データベースを新しいサーバに移行し、JDBC 接続プールの URL 属性が適切なロケーション参照を反映していることを確認する。 障害が発生したサーバに JDBC データベース ストアが存在していない場合は、データベースへのアクセスに影響はないので、変更は不要。
永続的なメッセージング-ファイル ストア	ファイルを新しいサーバに移行し、WebLogic Server ホーム ディレクトリ内のファイルのパス名が元のサーバにあったパス名と同じであることを確認する。
トランザクション	<servername>*.tlog という名前のすべてのファイルをコピーして、トランザクション ログを新しいサーバに移行する。このような移行は、一方のマシンに取り付け可能なデュアル ポート ディスクにトランザクション ログ ファイルを格納するか、または手動でファイルをコピーすることで実行できる。 ファイルが新しいサーバの異なるディレクトリにある場合は、サーバの [トランザクション ログファイルのプレフィックス] コンフィグレーション属性を更新してから新しいサーバを起動する。 注意: システムのクラッシュ後の移行では、サーバを新しい場所で再起動するときにトランザクション ログ ファイルが使用可能になっていることが特に重要である。そうしないと、クラッシュ時にコミット中だったトランザクションが適切に解決できず、その結果、アプリケーション データに矛盾が発生する場合がある。 未確定のトランザクションはすべてロールバックされる。

 

注意: JMS 永続ストレージに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープ サイズを、現在 JMS 永続ストレージに格納されているメッセージ数に比例するよう増加させてから、再起動してください。

新しい WebLogic Server の起動については、WebLogic Server の起動と停止を参照してください。 障害が発生したサーバの回復については、『WebLogic Server ドメイン管理』の「障害が発生したサーバの回復」を参照してください。

移行できる対象の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「移行可能サービスをデプロイ、活性化、および移行する」を参照してください。