|
|
|
|
|
|
| | | |
JMS の管理
以下の節では、WebLogic Server の Java Message Service（JMS）を管理する方法について説明します。
JMS と WebLogic Server
JMS は、エンタープライズ メッセージング システムにアクセスするための標準の API です。具体的な WebLogic JMS の機能は以下のとおりです。
次の図は、WebLogic JMS によるメッセージングの仕組みを示しています。
図17-1 WebLogic Server JMS のメッセージング
図で示されているように、WebLogic JMS はプロデューサ アプリケーションからメッセージを受信し、受け取ったメッセージをコンシューマ アプリケーションに配信します。
Administration Console を使用して、以下のコンフィグレーション属性を定義します。
WebLogic JMS では、一部のコンフィグレーション属性に対して、デフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。コンフィグレーション属性に対して無効な値を指定した場合や、デフォルト値が存在しない属性に対して値を指定しなかった場合は、再起動時に JMS が起動されません。製品には、サンプル サーバにおける examplesJMSServer のサンプル コンフィグレーションが用意されています。サンプル サーバの詳細については、『インストール ガイド』の「デフォルト、サンプル、および Pet Store サーバの起動」を参照してください。
WebLogic Server アプリケーションを以前のリリースから移行する場合、コンフィグレーション情報は自動的に変換されます（『WebLogic JMS プログラマーズ ガイド』の「既存のアプリケーションの移行」を参照）。
WebLogic JMS の属性をコンフィグレーションするには、以降の節、または『 Administration Console オンライン ヘルプ』で説明されている手順に従って、JMS オブジェクトを作成およびコンフィグレーションします。
WebLogic JMS をコンフィグレーションしたら、アプリケーションで JMS API を使用してメッセージの送受信ができるようになります。WebLogic JMS アプリケーションの開発の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。
注意: WebLogic JMS のコンフィグレーション プランを支援するために、『WebLogic JMS プログラマーズ ガイド』にはコンフィグレーション チェックリストがあります。このチェックリストを使用して、属性の要件や各種 JMS 機能をサポートするオプションを検討できます。
WebLogic Server の起動とJMS のコンフィグレーション
この節では、WebLogic Server および Administration Console の起動方法と、基本的な JMS 実装をコンフィグレーションするための手順を説明します。
デフォルト WebLogic Server の起動
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 を使用した基本的 JSM 実装のコンフィグレーション方法を説明します。
注意: ストアのコンフィグレーションの詳細については、 ストアのコンフィグレーションを参照してください。
注意: JDBC 接続プールのコンフィグレーションの詳細については、 Administration Console による JDBC 接続プール、マルチプール、およびデータソースのコンフィグレーションと管理 を参照してください。
注意: JMS テンプレートのコンフィグレーションの詳細については、 JMS テンプレートのコンフィグレーションを参照してください。
注意: JMS サーバのコンフィグレーションの詳細については、 JMS サーバのコンフィグレーションを参照してください。
注意: 送り先のコンフィグレーションの詳細については、 送り先のコンフィグレーションを参照してください。
注意: 接続ファクトリのコンフィグレーションの詳細については、 接続ファクトリのコンフィグレーションを参照してください。
JMS サーバは、クライアントの代わりに接続およびメッセージ リクエストを管理するサーバです。
JMS サーバを作成するには、Administration Console の [JMS｜サーバ] ノードを使用して、以下を定義します。
注意: JMS サーバのデプロイメントは、接続ファクトリやテンプレートのデプロイメントとは異なります。JMS サーバは 1 つのサーバにデプロイされます。接続ファクトリやテンプレートは、複数のサーバで同時にインスタンス化されます。
JMS サーバを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS サーバ」を参照してください。
接続ファクトリは、JMS クライアントが JMS 接続を作成することを可能にするオブジェクトです。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。接続ファクトリを定義およびコンフィグレーションして、あらかじめ定義された属性で接続を作成します。WebLogic Server では、起動時に接続ファクトリが JNDI スペースに追加され、アプリケーションが WebLogic JNDI を使用して接続ファクトリを取り出します。
システム管理者は、複数の接続ファクトリをコンフィグレーションし、対象を使用してそれらを WebLogic サーバに割り当てることで、クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスを確立できます。各接続ファクトリは、複数の WebLogic サーバにデプロイできます。JMS クラスタ化の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の基礎」を参照してください。
接続ファクトリをコンフィグレーションするには、Administration Console の [接続ファクトリ] ノードを使用して、以下を定義します。
close() メソッドを onMessage() メソッドから呼び出せるかどうか
WebLogic JMS では、デフォルトでweblogic.jms.ConnectionFactory という 1 つの接続ファクトリが用意されています。 すべてのコンフィグレーション属性は、このデフォルトの接続ファクトリのデフォルト値に設定されています。デフォルトの接続ファクトリの定義がアプリケーションに適用できる場合は、さらに接続ファクトリのコンフィグレーションを行う必要はありません。
注意: デフォルトの接続ファクトリを使用する場合は、接続ファクトリがデプロイされる可能性のある JMS サーバを限定することができません。特定の JMS サーバを対象にする場合は、新しい接続ファクトリを作成し、適切な JMS サーバの対象を指定してください。
接続ファクトリを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ」を参照してください。
接続ファクトリの属性の中には、動的にコンフィグレーションできるものもあります。動的な属性が実行時に変更された場合、新しく設定された値は新規接続に対してのみ有効になります。既存の接続の動作には影響しません。
送り先では、キュー (ポイント ツー ポイント）か JMS サーバ用のトピック（Push / Sub）かが識別されます。JMS サーバを定義したら、JMS サーバごとに 1 つまたは複数の送り先をコンフィグレーションします。
送り先は、明示的にコンフィグレーションすることも、送り先テンプレートを使用してコンフィグレーションすることもできます。送り先テンプレートを使用すると、似た属性設定を持つ複数の送り先を定義できます（ JMS テンプレートのコンフィグレーションを参照）。
送り先を明示的にコンフィグレーションするには、Administration Console の [送り先] ノードを使用して、以下のコンフィグレーション属性を定義します。
送り先を作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS の送り先」を参照してください。
送り先の属性の中には、動的にコンフィグレーションできるものもあります。属性が実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。
JMS テンプレートを使用することによって、似た属性設定を持つ複数の送り先を効率的に定義できます。JMS テンプレートには、以下のような利点があります。
JMS テンプレートのコンフィグレーション属性を定義するには、Administration Console の [テンプレート] ノードを使用します。JMS テンプレートに対してコンフィグレーションできる属性は、送り先に対してコンフィグレーションされる属性と同じです。これらのコンフィグレーション属性は、それらを使用する送り先によって継承されます。ただし、以下の例外があります。
送り先に対して明示的に定義されない属性には、デフォルト値が割り当てられます。デフォルト値が存在しない場合は、必ず、JMS テンプレートで値を指定するか、または送り先の属性のオーバーライド値として値を指定します。そうしないと、コンフィグレーション情報は不備な状態のままとなります。その場合、WebLogic JMS コンフィグレーションは失敗し、WebLogic JMS が起動しません。
JMS テンプレートを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS テンプレート」を参照してください。
特定の送り先に対してソート順を定義するには、送り先キーを使用します。
送り先キーを作成するには、Administration Console の [送り先キー] ノードを使用して、以下のコンフィグレーション属性を定義します。
送り先キーを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS の送り先キー」を参照してください。
永続ストレージは、永続的なメッセージングに使用されるファイルまたはデータベースで構成されます。ファイル ストアまたはデータベース ストアを作成するには、Administration Console の [ストア] ノードを使用して、以下のコンフィグレーション属性を定義します。
警告: JDBC データベース ストアで使用するトランザクション（XA）接続プールをコンフィグレーションすることはできません。詳細については、 JMS JDBC トランザクションを参照してください。
JMS 永続ストレージに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープ サイズを、現在 JMS 永続ストレージに格納されているメッセージ数に比例して増やします。その後、サーバをもう一度再起動してください。ヒープ サイズを設定する方法の詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic Server アプリケーションのチューニング」を参照してください。
ストアの作成およびコンフィグレーションの手順については、『Administration Console オンライン ヘルプ』の「JMS ファイル ストア」（ファイル ストアに関する情報）および 「JMS JDBC ストア」（JDBC データベース ストアに関する情報）をそれぞれ参照してください。
JMS JDBC ストアについて
JMS では、JDBC を使用することで、指定された JDBC 接続プールからアクセスできるデータベースに永続メッセージを格納できます。JMS データベースには、JDBC ドライバからアクセスできる任意のデータベースを指定できます。WebLogic JMS は、以下のデータベースに対するドライバを検出します。
weblogic.jar ファイルの weblogic/jms/ddl ディレクトリには、これらのデータベースに対する JMS DDL ファイルが収められています。このファイルは、実際には、JMS データベースのテーブルを作成する SQL コマンドを含むテキスト ファイルです。別のデータベースを使用するには、いずれかの .ddl ファイルをコピーして編集してください。
注意: WebLogic Server の配布キットに付属する JMS サンプルは、Cloudscape Java データベースで動作するようにセットアップされます。WebLogic Server には、Cloudscape の評価版が付属しており、demoPool データベースが用意されています。
既存の JMS JDBC ストアに何らかの破損が発生した場合は、utils.Schema ユーティリティを使って生成し直すことができます。詳細については、『WebLogic JMS プログラマーズ ガイド』の「JDBC データベース ユーティリティ」を参照してください。
JMS JDBC トランザクション
JMS JDBC ストアで使用するように、トランザクション (XA) JDBC 接続プールをコンフィグレーションすることはできません。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 接続プールに対してアクセス制御リスト（ACL）を制限することもできます。ACL を制限する場合は、WebLogic の system ユーザおよび JMS メッセージを送信するすべてのユーザが、このリストに含まれている必要があります。WebLogic Server セキュリティの管理の詳細については、 セキュリティの管理を参照してください。
JMS ストア テーブルのプレフィックス
JMS データベースには、自動的に生成され、JMS 内部で使用されるシステム テーブルが 2 つあります。
プレフィックス名は、この永続ストレージ内の JMS テーブルを識別します。ユニークなプレフィックスを指定すると、同一データベース内に複数のストアが存在できます。プレフィックスは、JDBC ストアをコンフィグレーションする際に Administration Console でコンフィグレーションします。プレフィックスは、DBMS で完全修飾名が必要な場合、または 2 つの WebLogic Server の JMS テーブルを区別する必要がある（1 つの DBMS で複数のテーブルを格納できるようにする）場合にテーブル名の前に付けられます。
警告: データに障害が発生するので、2 つのJMS ストアを同じデータベース テーブルで使用することはできません。
プレフィックスは、JMS テーブル名に付加されたときに有効なテーブル名になるように、次の形式で指定します。
[[[
catalog.]schema.]prefix]JMSStore
catalog は DBMS が参照するシステム テーブルのセットを識別し、schema はテーブル オーナの ID に変換します。たとえば、JMS 管理者はプロダクション データベースで販売部門用の固有のテーブルを次のようにして保持できます。
[[[Production.]JMSAdmin.]Sales]JMSStore
注意: Oracle などの一部の DBMS ベンダの場合、設定または選択するカタログがないので、このフォーマットは [[schema.]prefix] となります。詳細については、DBMS のマニュアルで完全修飾テーブル名の作成および使用方法を参照してください。
JMS ストア向けの JDBC 接続プールの推奨設定
WebLogic Server が備える堅牢な JDBC 接続プールは、障害が発生したデータベースがオンラインに戻った時点で、自動的に再接続を行うことができます。WebLogic Server を再起動する必要はありません。この機能を利用して、JMS JDBC ストアをさらに堅牢なものにするには、JMS JDBC ストアに関連付けられた JDBC 接続プールに対し、次の属性をコンフィグレーションします。
TestConnectionsOnReserve="true"
TestTableName="[[[catalog.]schema.]prefix]JMSState"
サーバ セッション プールを使用すると、アプリケーションで複数のメッセージを並行して処理できます。JMS サーバを定義した後、各 JMS サーバに 1 つまたは複数のサーバ セッション プールをコンフィグレーションします。
Administration Console の [セッション プール] ノードを使用して、以下のコンフィグレーション属性を定義します。
セッション プールを作成およびコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JMS セッション プール」を参照してください。
セッション プールの属性の中には、動的にコンフィグレーションできるものもありますが、新しい値はセッション プールが再起動されるまで有効になりません。
接続コンシューマは、サーバ セッションと取り出し、メッセージを処理するキュー（ポイント ツー ポイント）またはトピック（Pub/Sub）です。セッション プールを定義した後、各 JMS サーバに 1 つまたは複数の接続コンシューマをコンフィグレーションします。
接続コンシューマをコンフィグレーションするには、Administration Console の [セッション プール] ノードを使用して、以下のコンフィグレーション属性を定義します。
接続コンシューマを作成およびコンフィグレーションする場合に使用する、接続コンシューマの各コンフィグレーション属性の詳細については、Administration Console オンライン ヘルプの「JMS 接続コンシューマ」を参照してください。
Administration Console を使用すると、JMS サーバ、接続、セッション、送り先、メッセージ プロデューサ、メッセージ コンシューマ、サーバ セッション プール、恒久サブスクライバといった JMS オブジェクトに関する統計をモニタできます。
サーバの実行中は、JMS 統計は増え続けます。統計は、サーバを再起動するときにのみリセットされます。
注意: WebLogic Server への JMS 接続のモニタについては、Administration Console オンライン ヘルプの「サーバ」を参照してください。
JMS オブジェクトのモニタ
JMS モニタ情報を表示するには、次の操作を行います。
JMS サーバの情報が、右ペインに表示されます。
モニタされている情報の詳細については、Administration Console オンライン ヘルプを参照してください。
恒久サブスクライバのモニタ
送り先トピックで動作している恒久サブスクライバを表示するには、次の操作を行います。
JMS 送り先情報が右ペインに表形式で表示されます。[Durable Subscribers] カラムには、表に示されている送り先トピックに対して実行されている恒久サブスクライバの数が表示されます。
モニタされている情報の詳細については、Administration Console オンライン ヘルプを参照してください。
以降の節では、WebLogic Server JMS で使える管理者用パフォーマンス チューニング機能を実装することにより、アプリケーションの能力を最大限に引き出す方法を説明します。
永続性ストア
以降の節では、WebLogic Server JMS で永続性ストアを使用する場合のチューニング オプションについて説明します。
WebLogic Server JMS ファイル ストアでは、デフォルトで同期書き込みを使用することで最新のメッセージの整合性を保証します。通常、同期書き込みを無効にすると、ファイル ストアのパフォーマンスは大幅に向上します。その代わり、オペレーティング システムがクラッシュしたり、ハードウェアの障害が発生したりした場合には、メッセージがトランザクション対応であっても、送信したメッセージが失われたり、同じメッセージを重複して受信したりする可能性があります。オペレーティング システムでは通常のシャットダウン時に未処理の書き込みをすべてフラッシュするので、オペレーティング システムをシャット ダウンするだけではこうしたエラーは発生しません。こうしたエラーは、ビジー状態のサーバの電源を遮断することでエミュレートできます。
注意: 少なくとも 1 つの JMS ベンダでは同期書き込みをデフォルトで無効にしており、このベンダの場合のみ、受信に関して同期書き込みを無効にしたまま、送信に関して有効にすることができます。
WebLogic Server 上で実行されているすべての JMS ファイル ストアに対する同期書き込みを無効にするには、次のコマンドライン プロパティを設定します。
-Dweblogic.JMSFileStore.SynchronousWritesEnabled=false
JMS ファイル ストアに対する同期書き込みを無効にするには、次のように設定します。
-Dweblogic.JMSFileStore.store-name.SynchronousWritesEnabled=false
プロパティを両方とも設定すると、最初に設定したプロパティは後の設定でオーバーライドされます。同期書き込みが無効化された場合、ログ メッセージが生成されます。このメッセージを確認すると、コマンドライン プロパティが有効になっていることがわかります。
メッセージ ページング機能を利用すると、メッセージの負荷がピーク状態にある間、仮想メモリを解放することができます。この機能は、大きなメッセージ空間を使用するアプリケーションに対して大きな利点があります。
JMS メッセージ ページングを使うと、永続メッセージと非永続メッセージの両方について、永続メッセージがデータをメモリにキャッシュしていても、メモリを節約できます。ページングされた永続メッセージは、引き続き標準のバッキング ストア (ファイルまたはデータベース) に書き込まれます。また、ページングされた非永続メッセージは、別途コンフィグレーションされる JMS サーバのメッセージ ページング ストアに書き込まれます。
メッセージがページングアウトされても、メッセージが占めていたメモリがすべて解放されるわけではありません。検索、ソート、フィルタなどの処理で使用するため、メッセージのヘッダーとプロパティはメモリに残っています。
ページングのコンフィグレーション
ページングをコンフィグレーションして有効にしないと、すべてのメッセージは (永続メッセージであっても) メモリに保持されます。Administration Console を使用して、新規または既存の JMS サーバまたはその送り先に対してページングをコンフィグレーションできます。[JMS｜サーバ] ノードの属性を使用して、JMS サーバのページング ストアを指定したり、バイトまたはメッセージ ページングを有効にしたり、ページングを開始および停止するバイト/メッセージの最大および最小しきい値をコンフィグレーションしたりすることができます。
同様に、[送り先] ノードの属性を使用して、JMS サーバでコンフィグレーションされているすべてのトピックおよびキューのバイト/メッセージ ページングをコンフィグレーションできます。送り先は、JMS サーバ用にコンフィグレーションされているページング ストアを使用します。
また、JMS テンプレートを使用して複数の送り先をコンフィグレーションする場合、[テンプレート] ノードの属性を使用して、すべての送り先のページングをすばやくコンフィグレーションできます。特定の送り先に関してテンプレートのページング コンフィグレーションをオーバーライドする場合、どの送り先に対してもページングを有効または無効にできます。
新規の JMS サーバ、テンプレート、および送り先（トピックまたはキュー）のコンフィグレーション手順については、Administration Console オンライン ヘルプの「JMS サーバ」、「JMS 送り先」、および「JMS テンプレート」を参照してください。
注意: パフォーマンスをチューニングするために、ページングのしきい値をいつでも有効な値に変更できます。ただし、ページを有効にすると、バイトまたはメッセージしきい値を -1 にリセットしてページングを動的に無効にすることはできません。ページングの発生を防止するには、バイト/メッセージの最大しきい値を非常に大きな値（最大値は 263 -1）に設定して、ページングが開始されないようにします。
JMS サーバのページング ストアのコンフィグレーション
JMS サーバごとに専用のページング ストアを用意する必要があります。このページング ストアは、JMS サーバとその送り先に対する非永続メッセージをページングアウトするためだけに使用されます。JMS JDBC ストアはパフォーマンスが悪く現実的な利点がないので、JDBC ストアではなく JMS ファイル ストアを使用するのが最善です。
新しいページング ストアをコンフィグレーションするには、次の手順に従います。
JMS サーバのページングのコンフィグレーション
既存の JMS サーバでページングをコンフィグレーションして有効にするには、次の手順に従います。
注意: 各 JMS サーバは、それぞれ独自の永続ストレージを使用する必要があります。
JMS テンプレートのページングのコンフィグレーション
JMS テンプレートを使用することによって、似た属性設定を持つ複数の送り先（トピックまたはキュー）を効率的に定義できます。送り先用のテンプレートでページングをコンフィグレーションするには、次の手順に従います。
送り先のページングのコンフィグレーション
JMS テンプレートを使用しないで送り先のページングをコンフィグレーションする場合、以下の手順に従います。
注意: JMS テンプレートを使用して送り先をコンフィグレーションした場合、送り先のバイト/メッセージ ページングを明示的にコンフィグレーションすると、テンプレートのコンフィグレーションはオーバーライドされます。詳細については、 JMS テンプレートのページングをオーバーライドする送り先のコンフィグレーションおよび JMS のコンフィグレーションを参照してください。
JMS テンプレートのページングをオーバーライドする送り先のコンフィグレーション
テンプレートの設定をオーバーライドして特定の送り先のページングを有効または無効にする場合、次の手順に従います。
JMS のページング属性
以降の節では、WebLogic Server JMS で使用可能なページング属性について簡単に説明します。
JMS サーバのページング属性
表 17-1 では、JMS サーバでのページングをコンフィグレーションするときに定義するページング属性について説明します。JMS サーバの属性の詳細、および属性の有効な値とデフォルト値については、Administration Console オンライン ヘルプの「ドメイン」を参照してください。
JMS テンプレートのページング属性
表 17-3 では、JMS テンプレートで送り先のページングをコンフィグレーションするときに定義するページング属性について説明します。JMS テンプレートの属性の詳細、および属性の有効な値とデフォルト値については、Administration Console オンライン ヘルプの「JMS テンプレート」を参照してください。
JMS 送り先のページング属性
表 17-3 では、送り先に関するページングをコンフィグレーションするときに定義するページング属性について説明します。JMS 送り先の属性の詳細、および属性の有効な値とデフォルト値については、Administration Console オンライン ヘルプの「JMS の送り先」を参照してください。
注意: サーバのページングが有効で、送り先レベルのページングが指定した送り先に関して無効になっている場合、サーバのページングが開始されると、送り先のメッセージはページングされます。ただし、送り先レベルのページングが指定した送り先に関して無効になっている場合、送り先のメッセージ数がその送り先の最大しきい値を超えても、メッセージはページングされません。
ページングのしきい値属性
表 17-4 では、JMS サーバ、テンプレート、および送り先で使用可能なバイトおよびメッセージ ページングのしきい値について簡単に説明します。JMS サーバ、テンプレート、および送り先の属性の詳細と、属性の有効な値およびデフォルト値については、Administration Console オンライン ヘルプの「JMS サーバ」、「JMS テンプレート」、および「JMS の送り先」を参照してください。
|
属性 |
説明 |
|---|---|
|
[最大バイトしきい値] |
バイト数がこのしきい値を超えるとページングが開始される。 |
|
[最小バイトしきい値] |
バイト数がこのしきい値を下回るとページングが停止される。 |
|
[最大メッセージしきい値] |
メッセージ数がこのしきい値を超えるとページングが開始される。 |
|
[最小メッセージしきい値] |
メッセージ数がこのしきい値を下回るとページングが停止される。 |
しきい値は、サーバ、テンプレート、および送り先に対して次のように定義します。
以降の節では、システムの障害発生時に WebLogic Server インスタンスを再起動または交換する方法と、そうした障害の後、JMS アプリケーションを正常に終了するためのプログラミングの考慮事項について説明します。
WebLogic Server に障害が発生した場合、システムの回復方法には、以下の 3 種類があります。
障害が発生したサーバ インスタンスを再起動する、または障害が発生したサーバと同じ IP アドレスを使用して新しいサーバ インスタンスを起動する場合は、 WebLogic Server の起動と停止にある説明に従ってサーバを起動し、サーバ プロセスを開始します。
障害が発生したサーバとは異なる IP アドレスを使用して新しいサーバ インスタンスを起動するには、次の手順に従います。
注意: JMS 永続ストレージに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン（JVM）のヒープ サイズを、現在 JMS 永続ストレージに格納されているメッセージ数に比例するよう増加させてから、再起動してください。
WebLogic Server の障害発生時に正常に終了するよう、JMS アプリケーションをプログラミングすることもできます。次に例を示します。
|
|
|