9. JMS

JMS の注意・制限事項について説明します。

9.1. 永続ストア利用時の注意点

永続ストアを変更（ファイルストア⇔ JDBC ストア）した場合、それまでに永続化された情報（メッセージ、送信先、永続サブスクリプション、トランザクション）は引き継がれないことに注意してください。
V8.2 より永続ストアを変更しています。V8.2 より前のバージョンで利用していたJDBCストアのデータは引き継ぐことはできません。旧バージョンと同じJMSサーバインスタンス識別子 (jdbcStoreBrokerid) を利用する場合は、テーブルを再作成する必要があります。その場合、次の手順で再作成してください。
1. wojmsdbmgr コマンドの delete oldtbl サブコマンドを実行して旧バージョンのテーブルを削除します。
2. wojmsdbmgr コマンドの recreate tbl サブコマンドを実行してテーブルを再作成します。
V8.42 より前のバージョンにおいて、JDBC ストアの DBMS として Microsoft SQL Server を利用していた場合に、JMS サービスを再起動すると、永続サブスクリプションが消失する問題がありました。この問題に該当する場合、V8.42 以降の wojmsdbmgr コマンドにより、テーブルを再作成する必要があります。なお、テーブルの再作成では、それまでに永続化された情報 (メッセージ、送信先、永続サブスクリプション、トランザクション) を引き継ぐことはできません。

9.2. ユーザ管理について

WebOTX ドメイン認証では、クライアントからの認証要求で、MD5 ダイジェスト化したパスワードを送信することができません。パスワードの MD5 ダイジェスト化送信を利用する際は、JMS認証を使用してください。
ユーザ管理方式を変更する際は、ユーザリポジトリの設定値に誤った値を指定しないでください。運用管理操作でのJMSサーバの停止ができなくなります。ユーザ管理方式の変更についての詳細は、[ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.3. その他の設定項目・設定方法 > 1.7.3.10. ユーザ管理方式の設定 ] を参照してください。

9.3. Oracle OCI ドライバの利用について

Oracle の OCI ドライバを利用する場合の設定については、[ 6. JDBCデータソース > 6.1. Oracleご利用時の注意・制限事項 ] を参照してください。

9.4. Java EE アプリケーションからの SSL 通信利用について

Java EE 環境下で動作するアプリケーション (メッセージドリブン Bean (MDB) など) では、コネクションファクトリリソースの「コネクションタイプ」は有効になりません。
Java EE アプリケーションで SSL 通信を利用する場合は、コネクションファクトリリソースのプロパティとして、「 MessageServiceAddressList=<wojmsBrokerHostName>:<wojmsBrokerHostPort>/ssljms 」を設定してください。
<wojmsBrokerHostName>は「JMS サーバのホスト名」の値を、<wojmsBrokerHostPort>は「JMS サーバのホストのポート番号」の値を指定します。
統合運用管理ツールで設定する場合：

「WebOTX 管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMS リソース」-「コネクションファクトリリソース」-「<JNDI 名>」-【プロパティの設定】操作で設定します。

運用管理コマンドで設定する場合：
set コマンドで指定します。
```
otxadmin> set server.resources.jms-resource.jms-connection-factory.<JNDI名>.property.MessageServiceAddressList=<wojmsBrokerHostName>:<wojmsBrokerHostPort>/ssljms
```
設定方法の詳細は、[ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.3. その他の設定項目・設定方法 > 1.7.3.7. SSL通信を利用するための設定 ] を参照してください。

9.5. 自動再接続機能について

DUPS_OK_ACKNOWLEDGE 応答確認モードでは、自動再接続機能は使用できません。

9.6. JMS サーバクラスタの利用について

同一ホストで JMS サーバクラスタを構成する場合は、JMS サーバインスタンス識別子をホスト内で一意にしておく必要があります。JMS サーバインスタンス識別子の設定方法は以下のとおりです。
統合運用管理ツールで設定する場合：

「WebOTX 管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMS サービス」-【プロパティの設定】操作で設定します。
instance-name=<JMSサーバインスタンス識別子>

運用管理コマンドで設定する場合：
set コマンドで指定します。
```
otxadmin> set server.jms-service.property.instance-name=<JMSサーバインスタンス識別子>
```
設定方法の詳細は、[ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.3. その他の設定項目・設定方法 > 1.7.3.15. JMSサーバクラスタを利用するための設定 ] を参照してください。
クラスタに属する JMS サーバのアドレスリスト (clusterBrokerList) には、ホスト名として "127.0.0.1" は指定できません。
マスターブローカを設定している場合、マスターブローカである JMS サーバが起動するまで、他の JMS サーバは起動しません。他の JMS サーバは、マスターブローカの起動を待ち合わせるため、一時停止状態になります。
- マスターブローカが起動しない状態のまま、JMS サーバクラスタの設定を解除すると、他の JMS サーバが一時停止状態のままになる場合があります。このときは、wojmscmd resume bkr コマンドで JMS サーバを再開してください。
```
# wojmscmd resume bkr -u admin -p adminadmin -otxdomain <ドメイン名>
```
マスターブローカを設定している場合、マスターブローカが停止すると、以下の操作を行うことができなくなります。
- 物理的な送信先の生成／削除／プロパティ更新
- 永続サブスクリプションの削除
統合運用管理ツールでは、接続したドメインのデフォルトの JMS サーバの情報だけが参照できます。また、統計情報は、JMS サーバクラスタ内で統合された情報ではなく、そのドメインの JMS サーバのみの情報となります。
JMS サーバクラスタ構成で自動再接続機能は利用できません。
JMS サーバクラスタを起動する場合は、各 JMS サーバの設定を一致させて起動する必要があります。設定が一致していない場合、JMS サーバは起動しません。
JMS サーバクラスタ構成では、送信先のアクティブコンシューマの最大数 (server.jms-service.jms-physical-destination.<送信先名>.maxNumActiveConsumers) は、無制限 (-1) で利用してください。

9.7. JMS リソースについて

JMS サーバ停止中に JMS リソースを生成することはできません。
Foundation / Standard / Enterprise で、コネクションファクトリリソースをルックアップできない場合、JMXエージェント(エージェントプロセス)上でリソースをロードする必要があります。ロードするための設定は以下の通りです。
統合運用管理ツールで設定する場合：

「WebOTX 管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「コネクタリソース」-「<JNDI名>」-「JMXエージェント上でロードする」をチェック

運用管理コマンドで設定する場合：
set コマンドで指定します。
```
otxadmin> set server.resources.connector-resource.<JNDI名>.use-jmx-agent=true
```
V8.2 では、コネクションファクトリリソースの属性を変更しています。V8.2 より前のバージョンから、V8.2 以降のバージョンの JMS リソースをルックアップする場合は、次の制限があります。

V8.1 より前のバージョンの場合：

本バージョンのリソースは利用できません。com.nec.webotx.messaging.InvalidPropertyException 例外が発生します。

V8.1 の場合：

com.nec.webotx.messaging.InvalidPropertyException 例外の警告が発生しますが、リソースは利用可能です。

9.8. 分散トランザクションの運用について

非 Java EE 環境下では JMS をグローバルトランザクションに参加させることはできません。
JMS を分散トランザクションに参加させる場合、JMS サーバへのコネクションファクトリをトランザクションサービスの JCA リソースとして登録する必要があります。その際、接続先が異なる JMS サーバ毎に１つだけコネクションファクトリを登録してください。同一の JMS サーバの複数のコネクションファクトリを登録すると、トランザクションのリカバリ処理が失敗することがあります。

例えば、次のように、接続先が同一のコネクションファクトリを３つ作成した場合、Queue や Topic の違いに関わらず、どれか１つを JCA リソースとして登録してください。

    jms/QueueConnectionFactory { wojmsBrokerHostName=host1, wojmsBrokerHostPort=9700 }
    jms/QueueConnectionFactory2 { wojmsBrokerHostName=host1, wojmsBrokerHostPort=9700 }
    jms/TopicConnectionFactory { wojmsBrokerHostName=host1, wojmsBrokerHostPort=9700 }

9.9. 再配信メッセージの順序保証について

再配信メッセージの順序保証が利用できるのは、次の環境に制限されます。
1. 送信先タイプはキューであること
  JMSサーバクラスタ構成では、送信先の「ローカル配信のみ (isLocalOnly) 」の設定を有効 (true) にして、ローカルコンシューマ (送信先が作成されたブローカに接続しているコンシューマ) だけにメッセージを配信するようにおく必要があります。
2. コンシューマのメッセージ受信がトランザクション内で行われていること
3. 送信先に接続するコンシューマ数は 1 であること
  送信先に接続できるコンシューマ数は、1 に制限されます。また、メッセージドリブン Bean (MDB) の場合は、多重度を 1 に制限しておく必要があります。
再配信メッセージの順序保証を利用する場合は、次のような動作になります。

優先順位を設定したメッセージ

1 件目は優先順位の最も高いものがコンシューマに配信されます。コンシューマがそのメッセージをロールバックした場合は、優先順位を無視してそのメッセージが再配信されます。 2 件目は、その次に優先順位の高いものが配信されます。

配信時間を設定したメッセージ

1 件目は、一番最初に指定時刻に達したメッセージがコンシューマに配信されます。コンシューマがそのメッセージをロールバックすると、配信時間を無視してそのメッセージが再配信されます。コンシューマがメッセージをロールバックしている間は、他のメッセージが指定時刻になっても配信されません。 2 件目は、その次に指定時刻に達したものが配信されます。

有効期限を設定したメッセージ

メッセージの再配信中に有効期限が切れた場合は、そのメッセージが破棄(または、転送)され、コンシューマには、その次のメッセージが配信されます。

再配信回数、再配信遅延時間、破棄メッセージ転送先の設定

いずれの設定も有効になります。コンシューマが 1 件目のメッセージを受信後、ロールバックすると、遅延時間に指定した時間だけ待ってそのメッセージが再配信され、再配信回数の上限を超えると、そのメッセージは破棄(または、転送)されます。その後、キュー内の 2 件目のメッセージが配信されます。
順序保証の設定を変更する場合は、送信先のコンシューマ数が 1 以下の状態で行ってください。複数のコンシューマが接続しているときに順序保証の設定を有効にしても、設定は無視されます。

9.10. WebOTX V5 との互換性について

WebOTX V5 との相互接続不可
WebOTX V6 以降では性能向上のため、通信プロトコルを中心に、大幅な実装変更を行いました。
このため、WebOTX V5 と WebOTX V6 以降では、ライブラリレベルでの相互接続性はありません。

ただし、アプリケーションレベルでは、次項の WebOTX 拡張機能を使用していなければ、そのまま利用することができます。
WebOTX 拡張機能のインタフェース変更
WebOTX V5 で作成したアプリケーションにおいて、次に示す API を利用している場合には新しい API への修正が必要となります。
1. 確認応答モード定数： NO_ACKNOWLEDGE
  パッケージ名の変更
      V5: jp.co.nec.WebOTX.jms.ClientSession.NO_ACKNOWLEDGE
            ↓
      V6以降: com.nec.webotx.messaging.ClientSession.NO_ACKNOWLEDGE
2. 配信時刻指定 API
  パッケージ名の変更
      V5: jp.co.nec.WebOTX.jms.MessageImpl.setDeliveryTime()
            ↓
      V6以降: com.nec.webotx.messaging.jmq.jmsclient.MessageImpl.setDeliveryTime()
3. 再配信遅延時間指定 API
  パッケージ名の変更
      V5: jp.co.nec.WebOTX.jms.ClientQueueConnection.createQueueSession()
            ↓
      V6以降: com.nec.webotx.messaging.ClientQueueConnection.createQueueSession()
  
      V5: jp.co.nec.WebOTX.jms.ClientQueueConnection.createTopicSession()
            ↓
      V6以降: com.nec.webotx.messaging.ClientQueueConnection.createTopicSession()
運用コマンドの変更
WebOTX V5 の互換コマンドは提供しておりません。以下のコマンドをご利用ください。
1. jmsadm （JMS サーバの起動と停止）
  JMSサーバの起動と停止には、WebOTXの運用管理コマンド(otxadmin)を使用してください。統合運用管理ツールから操作することも可能です。
  
  起動：
```
otxadmin> start-jms
```
  停止：
```
otxadmin> stop-jms
```
2. jmsmng （送信先の運用）
  送信先の生成等の運用には、WebOTXの運用管理コマンド(otxadmin)を使用してください。また、統合運用管理ツールでjms-service管理対象に対して操作することも可能です。
  
  生成：
```
otxadmin> create-jmsdest
```
  削除：
```
otxadmin> delete-jmsdest
```
  一覧：
```
otxadmin> list-jmsdest
```
  メッセージ廃棄ポリシーに相当する機能は、送信先の属性 (limitBehavior) として与えることができます。
  ただし、LIFO に相当するものはサポートしておりません。
3. jmslog （ログ採取レベルの変更）
  JMSサーバのログレベルを変更するには、WebOTXの運用管理コマンド(otxadmin)、もしくは統合運用管理ツールを使用してjms-service管理対象の属性値を変更してください。
  
  変更： otxadmin> set
  
  例)
```
otxadmin> set server.jms-service.loglevel=DEBUG
```
4. jmspasswd （管理者パスワードの変更）
  管理者パスワードの変更については、JMS固有の[ リファレンス集運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.4. JMS > 4.4.5. wojmsusermgr ] コマンドを使用してください。
  例)
```
wojmsusermgr update -u admin -p adminadmin -otxdomain domain1
```
プロパティファイルの変更
WebOTX V5 のプロパティファイルの変更点について説明します。
1. jms_service.properties
  以下の設定ファイルで定義してください。
  <WebOTX dir>\domains\<domain name>\wojms\instances\wojmsbroker\props\config.properties
  
  設定できるプロパティについては、[ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.1. JMS設定項目・設定方法 ] を参照してください。
  なお、WebOTX V5 のプロパティとの互換性はありません。
2. jms_client.properties
  WebOTX V6 以降では使用しません。
DUPS_OK_ACKNOWLEDGE 確認応答モードの実装変更
JMS 標準では実装依存となっている DUPS_OK_ACKNOWLEDGE 確認応答モードの実装を WebOTX V5 から変更しています。
WebOTX V5 では AUTO_ACKNOWLEDGE 確認応答モード相当の実装 (1件単位に確認応答を発行) でしたが、WebOTX V6 以降では 10 件単位に確認応答を発行します。

9.11. 他社JMSプロバイダ接続について

V8.1での接続実績は IBM WebSphere MQ V6 のみです。
V8.1では、JNDIによる連携方式のみをサポートします。リソースアダプタのプロパティ ProviderIntegrationMode にはjndiを指定してください。
WebOTX JNDIに永続化して登録した情報が参照できなくなる場合、永続化した登録情報の復元時にセキュリティ例外が発生していることが考えられます。
例えば、リフレクション権限が不足する場合には、次のような例外が発生します。
java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
セキュリティログ(${INSTANCE_ROOT}/logs/agent/webotx_security.log)で詳細を確認し、必要な権限を以下のセキュリティポリシファイルに追加してください。
${INSTANCE_ROOT}/config/server.policy

IBM WebSphere MQ V6に関して
- JMS標準の例外リスナによるコネクション切断検知ができないため、コネクタコネクションプール生成時のプロパティ ConnectionValidationEnabled を利用できません。
- 同じキューマネージャに対する受信と送信が2フェーズコミットメントになる場合は、リソースアダプタのプロパティ RMPolicy に OnePerPhysicalConnection を指定してください。
- メッセージドリブン Bean (MDB) のアダプタ内での再配信機能を有効にする場合は、リソースアダプタのプロパティ UseFirstXAForRedelivery に true を指定してください。

9.12. コネクタコネクションプールのプールオブジェクトの変更について

V8.11より、JMSリソースアダプタで利用するコネクタコネクションプールのプールオブジェクトを変更しています。JMSリソースアダプタを利用してJMSサーバとのコネクションを取得する場合、次の点に注意してください。

コネクションが不要になったら、必ずコネクションのクローズメソッドを呼び出すようにしてください。
Webコンテナや、EJBコンテナ上で動作するアプリケーションの場合、1つのコネクションに対して、アクティブな(クローズしていない)セッションは1つしか生成できません。
コネクションファクトリリソースに対してクライアントIDを指定していると、次のエラーが発生する可能性があります。
Exception caught: javax.jms.JMSException: WOJMSRA:CFA:allocation failure:createQueueConnection:Error in allocating a connection. Cause: WOJMSRA:MC:InvalidClientIDException-[C4052]: クライアント ID はすでに使用されています - MyClientID

このような場合は、次のいずれかの対処を行ってください。
- コネクションファクトリリソースで「クライアントIDの共有(server.resources.jms-resource.jms-connection-factory.connection-factory-name.wojmsEnableSharedClientID)」を行うように設定する
- コネクションファクトリリソースで「クライアントID(server.resources.jms-resource.jms-connection-factory.connection-factory-name.wojmsConfiguredClientID)」を設定せずに、アプリケーションで個別のクライアントIDを設定する
設定により、コネクタコネクションプールのプールオブジェクトを V8.11 より前のバージョンと同じにすることも可能です。
この設定は、アプリケーションサーバ上で動作するJMSコネクションファクトリリソースが利用するすべてのコネクタコネクションプールに影響します。
統合運用管理ツールで設定する場合：

「WebOTX 管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMS サービス」-【プロパティの設定】操作で設定します。
wojmsConnectionPooling=false

運用管理コマンドで設定する場合：
set コマンドで指定します。
```
otxadmin> set server.jms-service.property.wojmsConnectionPooling=false
```
詳細は、[ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.2. JMS設定項目一覧 > 1.7.2.2. JMSサービス ] を参照してください。

9.13. メッセージ移動について

有効期限切れメッセージの移動は、本バージョンでは未サポートです。
移動元の送信先がトピックの場合、次の制限があります。
- 移動対象は、永続サブスクリプションのものに限られます。
- 移動対象を抽出するためのセレクタは利用できません。
- 永続サブスクリプションは、次の状態のものが移動対象となります。
移動操作を行う場合は、事前に、移動元、および、移動先となる送信先を一時停止しておく必要があります。ALL による一時停止状態でない場合 (CONSUMERS_PAUSED や、PRODUCERS_PAUSED 状態) は、エラーになります。また、移動処理中に、送信先の再開をしないでください。
移動先となる送信先の制限値を超える場合は、移動できません。制限に関わる送信先の属性は、移動元と移動先で調整しておく必要があります。
性能のために事前配信しているメッセージ(JMSクライアントに一括配信しているがコンシューマが未受信のもの)については移動対象となりません。そのため、滞留数より実際の移動数が少なくなる場合があります。
コンシューマからの応答がなく、事前配信されているメッセージも移動したい場合は、そのコンシューマアプリケーションを停止させるか、JMS コネクションのクローズ操作 (close-jms-connection) でコネクションをクローズし、JMS サーバとのコネクションを切断してください。
移動対象 (通常メッセージ / 不達メッセージ / 有効期限切れメッセージ) を選択できるのは、移動元がキューの場合のみで、トピックの場合は指定された永続サブスクリプションに対するメッセージすべてが移動対象となります (通常メッセージ / 不達メッセージ / 有効期限切れメッセージの区別はありません)。
配信遅延時間が設定されているメッセージは、配信時刻に到達するまで移動できません。
移動前の送信先名 (WOJMSOriginalDestinaion メッセージプロパティ) は、複数回移動したとしても、その直前に格納されていた送信先名しか保持しません。
移動操作でエラーが発生して、移動するのをやめた場合、送信先再開後に新たなコンシューマがメッセージを受信すると、移動対象となっていたメッセージは再配信された状態(再配信フラグが設定されていたり、配信回数がカウントアップしている)場合があります。
移動操作中にメッセージの有効期限切れが発生すると、移動操作で次のようなエラーが発生します。

操作の実行に失敗しました。
オペレーション 'moveMessages' が 'jms-physical-destination' のRuntime MBeanにおいて失敗しました。
Target exception message: Unable to move messages: [Q1] メッセージ XXXXX がストアに見つかりませんでした

9.14. 送信先の制限到達時の振る舞いについて

送信先の制限到達時の振る舞い (limitBehavior) が REMOVE_OLDEST と REMOVE_LOW_PRIORITY の場合、メッセージが削除されてもプロデューサに通知されません。JMS サーバ内で暗黙的に削除されます。
送信先の制限到達時の振る舞い (limitBehavior) がREMOVE_LOW_PRIORITY の場合、削除対象は既に滞留しているメッセージから選択されます。新しいメッセージが削除されることはありません。

9.15. 滞留メッセージの優先順位変更について

コンシューマに事前配信されているメッセージの優先順位の変更はできません。優先順位を変更したい場合は、いったんコンシューマのプログラムを終了する必要があります。
再配信処理中メッセージの優先順位変更はできません。
再配信メッセージの順序保証を利用する場合は、メッセージの優先順位変更はできません。

9.16. C言語インタフェースについて

本バージョンでは、Solaris は未サポートです。