NEC Mark
WebOTX Manual V12.1 (第3版)

目次を表示

6.4. JMS

Java Message Service (JMS) とは、Java で非同期通信を実現するための標準 API です。この API を使用することで、メッセージ作成や、キューやトピックと呼ばれる送信先 (デスティネーション) を介したメッセージ送受信を容易に行うことができます。

WebOTX JMQ は、Jakarta Messaging 3.1 に準拠した機能を提供しています。また、JCA 2.1 に準拠したリソースアダプタ機能や、JMX 2.0 に対応した運用管理機能をサポートしています。

6.4.1. JMSの概要

JMS の概要について説明します。

6.4.1.1. メッセージングモデル

WebOTX JMQ では、次の2つのメッセージングモデルを提供します。配信対象のコンシューマアプリケーションの数に応じて、お使いになるモデルを選択してください。

ポイントツーポイント (PTP)

1つのプロデューサアプリケーションが、ただ1つのコンシューマアプリケーションにメッセージを送信する1対1通信のモデルです。デスティネーションオブジェクトを拡張したキューと呼ばれる名前付のオブジェクトを使います。プロデューサはこのキューにメッセージを送信し、コンシューマはこのキューからメッセージを受信します。

ポイントツーポイント (PTP)

パブリッシュ／サブスクライブ (Pub/Sub)

1つのプロデューサアプリケーションが、複数のコンシューマアプリケーションにメッセージを送信する1対ｎ通信のモデルです。デスティネーションオブジェクトを拡張したトピックと呼ばれる名前付オブジェクトを使います。ポイントツーポイントとは異なり同じメッセージを複数のコンシューマが受信することができます。

パブリッシュ／サブスクライブ (Pub/Sub)

6.4.1.2. メッセージタイプ

WebOTX JMQ では、次の5つのメッセージタイプを提供します。 JMS クライアントアプリケーション間で交換したいデータの構成に応じて選択することができます。

BytesMessage

バイト配列のメッセージです。コンシューマは受け取ったバイト配列の内容を解釈できる必要があります。

TextMessage

String 型のメッセージです。

MapMessage

「String オブジェクトの名前」と「Java プログラミング言語のプリミティブデータ型の値」のセットのメッセージです。名前を指定してランダムに値を読み込むことができます。

StreamMessage

Java プログラミング言語のプリミティブデータ型の値を含むStream のメッセージです。ランダムに値を読み書きすることはできません。コンシューマは、プロデューサが書き込んだ順番で読み込む必要があります。

ObjectMessage

Java プログラミング言語の直列化可能なオブジェクト (Java オブジェクト) のメッセージです。

6.4.1.3. メッセージの永続性モード

WebOTX JMQ では、メッセージ配信に関して、次の2つの永続性モードを提供します。メッセージの重要性に関して、2つのモードを選択することができます。

NON_PERSISTENT モード

メッセージは永続ストアに格納されず、回線障害等の要因でロストし、配信されないことがあります。ただし永続ストアにアクセスするためのオーバーヘッドが無いので高速なメッセージ配信を行うことができます。

PERSISTENT モード

メッセージは永続ストアに格納され、信頼性の高い配信を行うことができます。ただし永続ストアへのメッセージ格納のオーバーヘッドは発生します。

WebOTX JMQ では、永続データの格納先として、標準で提供しているファイルベースのデータストア、もしくはJDBC 対応データベースを利用することができます。

6.4.1.4. メッセージの確認応答

PERSISTENT モードの場合、プロデューサから送信されたメッセージは、WebOTX JMQ によって永続ストアに格納された後、コンシューマに送信されます。コンシューマでは、受信したメッセージに対して acknowledge メソッドを呼び出して、メッセージ受信完了をWebOTX JMQ に通知する必要があります。この通知を確認応答と呼びます。

WebOTX JMQ では、コンシューマからの確認応答を受けて、該当するメッセージを確認応答受信待ちリストから削除し、メッセージの永続情報を削除します。コンシューマは必要に応じてWebOTX JMQ に「確認応答を行っていないメッセージ」の再送要求を行うことができます。

WebOTX JMQ では、次の4つの確認応答モードを提供します。

AUTO_ACKNOWLEDGE

WebOTX JMQ で自動的に確認応答を行います。このモードでは、メッセージを受信するたびに毎回確認応答を発行します。コンシューマが明示的に確認応答を行う必要はありません。ただしメッセージの再送要求を行うことはできません。

CLIENT_ACKNOWLEDGE

コンシューマがWebOTX JMQ 提供のインタフェースを呼び出し、確認応答を行います。配信されたメッセージそれぞれに確認応答を行うこともできますが、配信された複数のメッセージに対して一括して確認応答を行うこともできます。また必要に応じてメッセージの再送要求を行うことができます。

DUPS_OK_ACKNOWLEDGE

WebOTX JMQ で自動的に確認応答を行います。このモードの動作はJMS の実装に依存しており、WebOTX JMQ では、10件のメッセージを受信すると確認応答を発行します。また必要に応じてメッセージの再送要求を行うことができます。

NO_ACKNOWLEDGE

確認応答が不要なWebOTX JMQ 独自の拡張モードです。確認応答のための通信が行われないため高速な配信が行えますが信頼性は低下します。メッセージの再送要求も行うことはできません。

6.4.1.5. メッセージの同期受信と非同期受信

WebOTX JMQ ではコンシューマがメッセージを受信するときのモードとして次の2つを提供します。

同期受信

メッセージが配信されるまでコンシューマアプリケーションはブロックされます。配信されるメッセージがない場合に、指定した時間が来るまでブロックされるようにしたり、まったくブロックされないようにしたりすることも可能です。

非同期受信

メッセージが配信されている、いないにかかわらずコンシューマアプリケーションはブロックされません。ただし、配信されたメッセージを受け取るためのリスナを登録する必要があります。メッセージが配信されるとこのリスナに通知され、コンシューマアプリケーションはメッセージを受信することができます。

コンシューマがメッセージ受信を待ち合わせている間に回線障害など、システムに障害が発生した場合、待ち合わせしているスレッドに異常が通知されない場合があります。WebOTX JMQ ではシステムに障害が発生した場合にアプリケーションに異常を通知する機能を提供しています。コンシューマは、メッセージを受信するために使うコネクションオブジェクトごとに例外リスナを登録することで該当するコネクションに障害が発生した場合、例外通知を受けることができます。この例外通知を受け取って必要な復旧処理を行うことができます。

6.4.1.6. トランザクション

JMS でのトランザクションは、プロデューサからのメッセージ送信、コンシューマでのメッセージ受信を最小単位としています。

プロデューサからのコミット要求でコンシューマへのメッセージ配信が開始され、コンシューマからのコミット要求でJMS サーバ内のメッセージが削除されます。また、プロデューサからロールバックが要求されると送信したメッセージは破棄され、コンシューマからロールバックが要求されると、コンシューマで受信したメッセージはJMS サーバ内で保持されます。コンシューマでロールバックされたメッセージは、トピックの場合同じサブスクライバに対して再送されますが、キューの場合どのレシーバに再送されるかは規定されていません。

WebOTX JMQ ではトランザクションを制御する方法として以下の2つの方法を提供します。1つ目は、JMS のローカルトランザクションを使用する方法で、2つ目は分散トランザクションを使用する方法です。それぞれの方法について以下に説明します。

ローカルトランザクション

JMS でローカルトランザクションを使用する場合は、Session オブジェクト生成時に、transacted パラメータにtrue を指定して、トランザクションセッションを生成する必要があります。トランザクションは最初にメッセージを送受信した時点で自動的に開始され、以降はコミット／ロールバックした時点で自動的に次のトランザクションを開始します。

分散トランザクション

JMS を分散トランザクションに参加させるには、JMS が提供するリソースアダプタを使用する必要があります。また、2フェーズコミットメントを使用する場合は、使用するリソースアダプタをトランザクションサービスのJCA リソースとして登録する必要があります。

トランザクションセッションではWebOTX JMQ がトランザクション処理を行うため独自の確認応答の制御を行います。したがってクライアントアプリケーションはメッセージの確認応答の制御を行うことはできません。確認応答モードの設定は無視されます。

トランザクションセッションの使い方については [ アプリケーションの開発> JMSアプリケーションの開発> プログラミング・開発ガイド> その他の機能を使用したプログラムの開発> JMSのトランザクション機能を使用したプログラム ] を参照してください。

6.4.1.7. メッセージのフィルタリング

WebOTX JMQ のメッセージには、メッセージの属性を表す標準のヘッダフィールドと、アプリケーション固有の情報を含めることができるプロパティフィールドがあります。

JMS サーバではプロデューサから送信されたメッセージのヘッダフィールド、プロパティフィールドに格納されている情報をもとにメッセージのフィルタリングを行い、必要なメッセージだけをコンシューマに配信することができます。フィルタリングにはセレクタと呼ばれる単純な構文の文字列を使い、コンシューマを作成するときに指定します。

フィルタリングを使って不要なメッセージの配信を抑制することでネットワークへの負荷を軽減する効果も得られます。

メッセージのフィルタリングの使い方については [ アプリケーションの開発> JMSアプリケーションの開発> プログラミング・開発ガイド> その他の機能を使用したプログラムの開発> メッセージのフィルタリングを使用したプログラム ] を参照してください。

6.4.2. メッセージのスケジューリング

WebOTX JMQ では、メッセージの配信時間をスケジューリングする独自の拡張機能を提供しています。プロデューサは、将来のある特定の時間にメッセージをコンシューマに配信することができます。

また、WebOTX JMQ では「確認応答を行っていないメッセージ」の再配信時間を遅延させる機能を提供しています。障害などでコンシューマがメッセージを受信する準備ができていないときに、メッセージの再配信を遅延させて、その間にメッセージを受信するための準備を行うことができます。

メッセージのスケジューリングの使い方については [ リファレンス> リソース> JMS> 拡張インタフェース ] を参照してください。

6.4.3. メッセージフロー制御

メッセージが滞留するような状況 (高負荷、コンシューマ遅延、コンシューマ不在) になると、メモリ不足によりパフォーマンス低下やプロセスダウンなどの問題を引き起こす可能性があります。WebOTX JMQでは、このような問題を未然に防ぐために、次のようなメッセージフロー制御に対応しています。

6.4.3.1. JMS サーバでの滞留抑止
サーバ単位での制御

すべての送信先で滞留するメッセージを監視して、JMS サーバ内での滞留を抑止することができます。サーバ全体で滞留可能なメッセージの最大数と総メモリ量を設定して制御します。

この他に、1つのメッセージで許容するサイズを制限する機能や、メッセージの有効期限を設定して定期的にメモリを回復させる機能も提供します。

送信先レベルでの制御

送信先に滞留するメッセージを監視して、JMS サーバ内での滞留を抑止することができます。送信先単位で、滞留可能なメッセージの最大数、総メモリ量、そしてその制限到達時の振る舞いを設定して制御します。制限到達時の振る舞いには、以下のものがあります。

6.4.3.2. JMS クライアントでの滞留抑止
コネクションレベルでの制御

コンシューマでのメッセージ処理が遅延すると、JMS クライアントに配信され続けるメッセージがJMS クライアント内に滞留することになります。これを抑止するためには、コネクション上のすべてのコンシューマ群での滞留可能なメッセージ数の制限値をコネクションファクトリに設定して制御します。JMS サーバは、この制限値に到達するとメッセージの配信を停止し、下回ると配信を再開します。

コンシューマレベルでの制御

個々のコンシューマ単位に、滞留可能なメッセージ数の制限値と配信を再開するポイントをコネクションファクトリに設定して制御します。JMS サーバは、この制限値に到達するとメッセージの配信を停止し、配信再開値を下回ると配信を再開します。

6.4.3.3. その他のフロー制御
制御メッセージのフロー促進

JMS サーバとクライアントの間では、メッセージの送受信だけでなく、確認通知のような数多くの制御データもやり取りされています。そのため、JMS サーバからクライアントに対するメッセージ配信が連続するような高負荷が続くと、確認通知が遅延することによってメッセージの滞留につながる場合があります。

この問題を回避するためには、メッセージを連続して配信する数の制限値をコネクションファクトリに設定して制御します。JMS サーバは、この制限値に到達すると一時的にメッセージの配信を停止して制御データのフローを促進します。

制御データを数多く使用するのは、次のような機能を利用する場合です。

6.4.4. マルチコンシューマ負荷分散

WebOTX JMQ では、接続している複数のコンシューマへの負荷分散配信機能を提供します。

6.4.4.1. Queue の場合

負荷分散の対象とするアクティブなコンシューマの数とそのバックアップとなるコンシューマの数を送信先に設定すると次のように制御します。

6.4.4.2. Topic の場合

Standard において、メッセージ・ドリブン Bean (MDB) をTP モニタ上で起動する場合、その多重度の設定によっては複数のコンシューマが動作します。WebOTX JMQ では、自動的に複数のコンシューマをひとつのグループとして扱い、Topic からの配信を同じグループの中のひとつのコンシューマに対してだけ行うように制御します。

グルーピングするには、次の情報を一致させる必要があります。

クライアント識別子は、次の方法で設定することができます。

MDB の場合は、クライアント識別子の共有を許可するフラグと共に必ず明示的に設定する必要があります。

6.4.5. セキュリティ

WebOTX JMQ では、ユーザ認証、アクセス制御、メッセージの暗号化の3つのセキュリティ機能を提供します。

6.4.5.1. ユーザ認証

JMS クライアントからのコネクション確立時に、指定したユーザ名とパスワードをあらかじめ定義されたユーザ管理情報と照合して認証を行います。

6.4.5.2. アクセス制御

JMS クライアントからの操作 (コネクション、送信先、送信先自動作成) に対して、あらかじめ定義されたアクセス制御情報を照合して承認を行います。

6.4.5.3. メッセージの暗号化

Java Secure Socket Extension (JSSE) に基づいた、サーバの自己署名型証明書によるメッセージのSSL暗号化に対応しています。メッセージを暗号化することで、機密性の高い重要な情報が外部に漏れないようにすることができます。

6.4.6. データストア

WebOTX JMQ では、永続化すべきデータの格納先として、標準で提供しているファイルベースのデータストア、もしくはJDBC 対応データベースを利用することができます。データストアには、次のような情報が格納されます。

6.4.7. コネクション制御スレッドのプール管理

WebOTX JMQ では、コネクションサービスでJMS クライアントとJMS サーバとの間で確立されるTCP コネクションを管理しています。これらのコネクションに必要なスレッドは、プール管理して有効に利用できるようになっています。プール管理はスレッドの最小数と最大数の2つを指定して制御します。

コネクションを確立してスレッドが必要になると、確保したスレッドをスレッドプールに順次追加していきます。最小数を超えると、コネクションを解放するタイミングに不要になったスレッドを、最小数を下回らない範囲で解放します。一時的な高負荷で最大数に到達した場合、それ以上の新たなスレッドは確保せずに、スレッドの空きができるまで待ち合わせます。

コネクションサービスは、サービスタイプとプロトコルタイプ別に4種類 (jms、admin、ssljms、ssladmin) 存在します。

6.4.8. 送信先の自動生成

WebOTX JMQ では、送信先の自動生成をサポートしています。通常は、運用管理コマンドなどからあらかじめ送信先を定義しておく必要がありますが、この機能を有効にすることにより、必要なタイミングで送信先が自動生成されるようになります。ただし、自動生成される送信先は、メッセージが存在しないと一定時間経過後に削除されますので、開発時の簡単な動作確認などの場合に有効です。

この機能を利用する場合には、あらかじめJMSサービスの属性で許可しておく必要があります。

6.4.9. 再配信の遅延と回数制限

ロールバックされたメッセージを再配信する時間の遅延と、再配信回数を制限することができる機能です。

遅延の設定については、コンシューマ用のAPI や、コネクションファクトリの属性でコンシューマごとに設定可能です。また、メッセージ・ドリブン Bean (MDB) では、コネクションファクトリの属性か配備記述子で設定可能です。

再配信回数の制限は、コンシューマが処理できないメッセージの存在が原因で、再配信が延々と行われるような状況に陥り、システム全体のスループットが低下してしまう事態を未然に防ぐような場合に利用します。 再配信回数の制限値に到達したメッセージは破棄されますが、破棄せずに別の送信先に蓄積することもできます (破棄メッセージの転送機能)。再配信の遅延時間と回数は、送信先の属性か、JMS サービスの属性として設定します。

6.4.10. 破棄メッセージの転送機能

再配信の回数制限値を超過したメッセージ (不達メッセージ) や、有効期限に到達したメッセージはデフォルトでは破棄されますが、これらをあらかじめ用意した送信先に転送することができる機能です。 この送信先からメッセージを取得するプログラムを作成し、ロギングやリカバリを行う処理を組み込むことが可能になります。

不達メッセージの転送先は、送信先の属性か、JMS サービスの属性として設定します。また、有効期限切れの転送先は、JMS サービスの属性として設定します。

JMS サーバクラスタの場合、転送先はコンシューマのホームブローカの送信先になります。

6.4.11. クライアント・サーバ間の相互監視

WebOTX JMQ は、サーバとクライアント間の相互通信にTCP/IP プロトコルを利用していますが、データ受信を主体としている場合、ネットワークの異常を検知できないような事象 (簡単な例だと、相手側のケーブルが抜けたような場合) が発生する場合があり、次のような問題を引き起こす可能性があります。

このような問題を防ぐために、クライアントアプリケーションのライブラリレベルで、JMS サーバとの接続を定期的にチェックする機能を提供しています。この機能はデフォルトで動作しますが、監視間隔は変更することができます。

6.4.12. JMSサーバクラスタ

JMS サーバの多重化を行うための機能です。JMS クライアントの接続数や、送受信メッセージ数の増加に応じて、JMS 利用システムを拡張することが可能になります。また、メッセージ・ドリブン Bean (MDB) 利用アプリケーションや、ESB によるメッセージ処理の負荷分散や異常時のサービス継続を実現します。

例えば、

といった利用法が考えられます。

ドメイン単位に1つのJMS サーバを起動しますので、JMS サーバの多重化を行う場合は、多重化する数だけドメインが必要になります。

トピックによる情報配信システム

ューによる業務受付システム

クラスタを構成するJMS サーバは、他のすべてのJMS サーバと相互に接続して、送信先の生成／削除、コンシューマの登録／削除といった情報を交換します。

クライアントは、コネクションファクトリの「アドレスリスト」を利用して、クラスタ内の1つのJMS サーバと直接通信し、そのJMS サーバが唯一のJMS サーバであるかのようにメッセージの送受信を行います。 実際には、クライアントが接続しているJMS サーバが他のJMS サーバと協調動作し、接続中のすべてのクライアントに対してメッセージ配信サービスを提供します。

クライアントの接続先は、JMS クライアントランタイムが、コネクションファクトリに設定された「アドレスリスト」から、プライオリティ (リストに記述された順番)、あるいは、ランダムに決定します。これにより、複数のJMS サーバ間でクライアントコネクションを分散させることが可能となります。

以降、JMS サーバクラスタ構成でのメッセージの送受信や、JMS サーバ間での情報の送受信の動作について説明します。

6.4.12.1. JMS サーバクラスタ内のメッセージ送受信

JMS サーバクラスタ構成では、各JMS サーバが送信先とコンシューマに関する以下の情報を共有しています。

これらの情報によって、各JMS サーバは、自身に接続しているプロデューサからのメッセージをリモートのコンシューマに配信することができるようになります。

一方、クライアントは、1つのJMS サーバに接続し、それがクラスタ内の唯一のJMS サーバであるかのようにメッセージの送受信を行います。このクライアントが接続したJMS サーバを「ホームブローカ」と呼びます。

クライアントの接続先は、一度接続すると以降は固定で、動的に変更されません。

上記のとおり、各JMS サーバはコンシューマの情報は共有しますが、プロデューサの情報は共有しません (プロデューサが追加されても、その情報はクラスタ内には伝播しません)。プロデューサから送信されたメッセージは、ホームブローカ上の送信先にのみ存在し、ホームブローカは、ローカル、リモートにかかわらず、受信可能なコンシューマが存在すればメッセージを配信するようになっています。

6.4.12.2. JMS サーバクラスタ内の送信先

物理的な送信先は、以下のような作成方法の違いによって、クラスタ内での伝播情報が異なります。

次に、伝播するものの一覧と、その範囲を示します。

表3.6.4.12-1
送信先種別 JMS サーバクラスタ内での情報伝播
運用管理コマンド／統合運用管理ツールで作成 作成 伝播する。
削除 伝播する。
自動生成 作成 プロデューサが接続する送信先が存在しない場合:伝播しない。プロデューサのホームブローカ上にのみ送信先が作成される。
コンシューマが接続する送信先が存在しない場合:伝播する。
削除 管理コマンドでの削除:伝播する。
自動削除:伝播しない。自動作成された送信先は、以下の場合に は、JMS サーバ毎に削除される。
  • 一定時間、コンシューマまたはメッセージがない場合
  • JMS サーバの再起動時に、その送信先にメッセージ がない場合
一時 作成 伝播する。
削除 伝播する。
6.4.12.3. 送信先の属性

送信先の属性は、クラスタ内のJMS サーバに伝播するものとしないものがあります。次に、その一覧を示します。

server.jms-service.jms-physical-destination.physical-destination-name :

表3.6.4.12-2
属性名 JMS サーバクラスタ内での情報伝播
コンシューマへのフロー制限数 consumerFlowLimitNum 伝播する
制限到達時の振る舞い limitBehavior 伝播する
アクティブコンシューマの最大数 maxNumActiveConsumers 伝播する
バックアップコンシューマの最大数 maxNumBackupConsumers 伝播する
ローカル配信のみ isLocalOnly 伝播する
ローカル配信優先 localDeliveryPreferred 伝播する
再配信時の順序保証 supportOrderedRedelivery 伝播する
再配信遅延時間 wojmsRedeliveryDelay 伝播する
再配信回数 wojmsRedeliveryLimit 伝播する
不達メッセージ転送先 wojmsRedeliveryDestination 伝播する
1メッセージ当たりの最大サイズ maxBytesPerMsg 伝播する
メッセージの最大数 maxNumMsgs 伝播する
プロデューサの最大数 maxNumProducers 伝播する
メッセージの最大合計サイズ maxTotalMsgBytes 伝播する
6.4.12.4. JMS サーバクラスタの同期化

JMS サーバクラスタ環境では、以下の情報が、すべての起動中のJMS サーバに即座に伝播するようになっています。

しかし、障害などで停止していたJMS サーバはこれらの変更通知を受け取ることができません。

この問題に対処するため、クラスタ内に、変更情報を記録するためのJMS サーバとして、「マスターブローカ」を設定することができます。再起動するJMS サーバは、マスターブローカが記録した変更情報を参照して、必要な更新を行ってから起動するため設定情報の同期を取ることが可能です。

マスターブローカは、JMS サーバクラスタ内で1つ設定します。マスターブローカを設定した場合、クラスタ内のJMS サーバはマスターブローカであるJMS サーバの起動を待ち合わせます。また、マスターブローカに障害が発生した場合、以下の操作は行うことができません。それ以外のメッセージ送受信などの処理はそのまま継続できます。

マスターブローカを設定しなかった場合、障害発生などで停止しているJMSサーバには、設定変更を反映することができません。

6.4.13. 再配信メッセージの順序保証

JMS サーバは、効率よくメッセージを配信するために、「メッセージフロー制御」で説明した機能により、メッセージをあらかじめコンシューマに事前配信しています。そのため、トランザクションのロールバックによってメッセージの再配信が行われた場合、そのメッセージは事前配信されたメッセージ群の最後尾に位置づけられてしまい、配信順序が狂ってしまいます。

再配信メッセージの順序保証なし

このように、トランザクションのロールバックが発生した場合でも配信順序を保証するための機能が「再配信メッセージの順序保証」です。フロー制御の設定は無効になり、メッセージの受信が確定するまでは、事前配信を行わないようにします。設定は、物理的な送信先単位に行います。

再配信メッセージの順序保証あり

再配信メッセージの順序保証が利用できるのは、次の環境に制限されます。

6.4.14. メッセージ送信機能

送信先に対する操作により、メッセージを送信する機能です。

コンシューマアプリケーションの開発や環境構築において、プロデューサアプリケーションを作成することなく、受信動作や設定の評価で利用できます。また、簡単なものであれば、コマンドベースでの送信機能を構築することができます。

次に、本メッセージ送信機能でサポートする設定項目を示します。なお、1回の操作で送信できるメッセージは 1件です。

表3.6.4.15-1
設定項目 説明 既定値
メッセージタイプ 送信するメッセージのタイプ
次のタイプを指定可能。
TextMessage : メッセージボディにString を含むもの
Message : メッセージボディのない軽量なメッセージ
BytesMessage : メッセージボディにバイト配列を含む もの 		TextMessage
メッセージボディの指定方法 メッセージボディの指定方法
text : メッセージボディに指定された文字列をボディそのものとして設定
file : メッセージボディに指定された文字列をファイル名として、指定されたファイルの内容をメッセージボディに設定 		text
メッセージボディ メッセージボディ
TextMessage の場合 : メッセージボディタイプのtext、file をサポート。
Message の場合 : メッセージボディなし。指定されていても無視する。
BytesMessage の場合 : メッセージボディタイプはfileのみ有効。指定されたファイルの内容をバイト配列に変換して設定する。 		-
配信モード (JMSDeliveryMode) メッセージを永続化するかどうか
PERSISTENT : 永続化する
NON_PERSISTENT : 永続化しない 		PERSISTENT
有効期限 (JMSExpiration) メッセージの有効期限 (ミリ秒) 0 (有効期限なし)
優先順位 (JMSPriority) メッセージの優先順位 (0-9) 4
相関ID (JMSCorrelationID) メッセージを対応付けるための文字列
指定可能な値は、String のみ。 		-
応答用送信先 (JMSReplyTo) メッセージを受信したコンシューマが返信する送信先 -
応答用送信先のタ イプ 応答用送信先のタイプ queue
タイプ (JMSType) 任意の文字列 -
配信遅延時間 配信遅延時間
WebOTX JMQ 固有の拡張機能で、相対時間 (秒) での指定のみ可能。 		0 (遅延時間なし)
メッセージプロパティ メッセージプロパティ
設定可能なプロパティ値は、String のみ。 		-

6.4.15. コネクションクローズ機能

JMS サービスに対する運用操作として、JMS クライアントとのコネクションを強制的にクローズする機能です。

何らかの異常が発生しているJMS クライアントのコネクションを強制的にクローズすることで、占有しているネットワークリソースの解放や、JMS クライアントが実装する例外リスナによる復旧を試みることができます。

コネクションクローズ機能

6.4.16. イベント通知機能

コネクション切断／再接続や、送信先に対するコンシューマの存在に関するイベントを通知する機能です。

6.4.16.1. コネクションイベント通知

コネクションイベントリスナを利用することによって、コネクション切断や、コネクション再接続のタイミングで通知を受けることが可能になります。 通知されるイベントでは、コネクションが切断された理由や、どのJMSサーバに再接続したかなどの情報が取得できます。

次に、コネクションイベントリスナが通知するイベントと、イベントから取得できる情報を示します。

表3.6.4.19-1
イベント 説明
ConnectionClosedEvent JMSサーバとの接続がクローズしたことを通知する。イベントオブジェクトから次の情報を取得できる。
  • コネクションがクローズされた原因を示すコード
    • CONNECTION_CLOSED_ERROR ： JMSサーバ側のエラーによるクローズ
    • CONNECTION_CLOSED_KILL ： 管理者がコネクションをクローズ
    • CONNECTION_CLOSED_LOST_CONNECTION ： ネットワークやJMSサーバ異常によるクローズ
    • CONNECTION_CLOSED_SHUTDOWN ： 管理者がJMSサーバをシャットダウンしたことによるクローズ
  • コネクションオブジェクト
  • 接続していたJMSサーバのアドレス
  • コネクションがクローズされる原因となったJMSException例外オブジェクト
ConnectionReconnectedEvent JMSサーバに再接続したことを通知する。イベントオブジェクトから次の情報を取得できる。
  • コネクションオブジェクト
  • 再接続したJMSサーバのアドレス
ConnectionReconnectFailedEvent JMSサーバとの再接続に失敗したことを通知する。イベントオブジェクトから次の情報を取得できる。
  • コネクションオブジェクト
  • 接続しようとしたJMSサーバのアドレス
  • コネクション再接続失敗の原因となったJMSException例外オブジェクト
6.4.16.2. コンシューマイベント通知

コンシューマイベントリスナを利用することによって、特定の送信先に対して、コンシューマが存在するかどうかの通知を受けることができます。 例えば、プロデューサアプリケーションでは、コンシューマの有無に基づいて、特定の送信先に対してメッセージ送信の開始や停止を行うことが可能になります。

次に、コンシューマイベントリスナが通知するイベントと、イベントから取得できる情報を示します。

表3.6.4.19-2
イベント 説明
ConsumerEvent 監視する送信先のコンシューマの接続状況を通知する。イベントオブジェクトから次の情報を取得できる。
  • コンシューマの接続状況を示すコード
    • CONSUMER_READY ： メッセージを受信できるコンシューマが存在する
    • CONSUMER_NOT_READY ： メッセージを受信できるコンシューマは存在しない。INACTIVE状態の永続サブスクリプションは「存在しない」とみなす
  • コネクションオブジェクト
  • イベントを送信したJMSサーバのアドレス
  • 送信先オブジェクト
6.4.16.3. 属性値について

説明中の各属性の詳細については、 [ 構築・運用 > 設定 > JMS > JMS設定項目一覧 ] を参照してください。

Copyright (C) 1998 - 2025 NEC Corporation. All rights reserved.