4.9. メッセージングサーバー設定の変更
JBoss EAP 7 では、JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になりました。ここでは、設定と関連するメッセージングデータの移行方法を説明します。
4.9.1. メッセージングサブシステムサーバー設定の変更
EAP_HOME/modules/system/layers/base/
にあった org.jboss.as.messaging
モジュール拡張は、 org.wildfly.extension.messaging-activemq
拡張モジュールに置き換えられました。
urn:jboss:domain:messaging:3.0
サブシステム設定ネームスペースは urn:jboss:domain:messaging-activemq:4.0
ネームスペースに置き換えられました。
管理モデル
ほとんどの場合で、要素名と属性名は以前のリリースとできる限り同じになるよう努力しています。以下の表は変更の一部を表しています。
表4.3 メッセージング属性のマッピング
HornetQ での名前 | ActiveMQ での名前 |
---|---|
hornetq-server | server |
hornetq-serverType | serverType |
connectors | connector |
discovery-group-name | discovery-group |
新しい messaging-activemq
サブシステム上で呼び出される管理操作は、/subsystem=messaging/hornetq-server=
から /subsystem=messaging-activemq/server=
に変更になりました。
migrate
操作を呼び出すと、既存の JBoss EAP 6 の messaging
サブシステム設定を JBoss EAP 7 の messaging-activemq
サブシステムに移行できます。
/subsystem=messaging:migrate
migrate
操作を実行する前に describe-migration
操作を呼び出して、既存の JBoss EAP 6 の messaging
サブシステム設定から JBoss EAP 7 サーバーの messaging-activemq
サブシステムへの移行を実行する管理操作のリストを確認することができます。
/subsystem=messaging:describe-migration
migrate
および describe-migration
操作は、自動的に移行されないリソースや属性の migration-warnings
のリストも表示します。
Messaging サブシステムの移行および前方互換性
messaging
サブシステムの describe-migration
および migrate
操作は、追加の設定引数を提供します。メッセージングを設定してレガシー JBoss EAP 6 クライアントが JBoss EAP 7 サーバーに接続できるようにするには、以下のようにブール値の add-legacy-entries
引数を describe-migration
または migrate
操作に追加します。
/subsystem=messaging:describe-migration(add-legacy-entries=true) /subsystem=messaging:migrate(add-legacy-entries=true)
ブール値の引数 add-legacy-entries
が true
に設定されていると、messaging-activemq
サブシステムが legacy-connection-factory
リソースを作成し、legacy-entries
を jms-queue
および jms-topic
リソースに追加します。
ブール値の引数 add-legacy-entries
が false
に設定されていると、messaging-activemq
サブシステムにはレガシーリソースが作成されず、レガシー JMS クライアントは JBoss EAP 7 サーバーと通信できません。これがデフォルト値になります。
前方互換性および後方互換性に関する詳細は、JBoss EAPConfiguring Messaging のBackward and Forward Compatibilityを参照してください。
管理 CLI の migrate
および describe-migration
操作の詳細は、管理 CLI の移行操作 を参照してください。
forward-when-no-consumers 属性の動作変更
JBoss EAP 7 では、forward-when-no-consumers
属性の動作が変更になりました。
JBoss EAP 6 では、forward-when-no-consumers
が false
に設定され、クラスターにコンシューマーがない場合に、メッセージはクラスターのすべてのノードへ再分散されました。
この動作は JBoss EAP 7 では変更になりました。forward-when-no-consumers
が false
に設定され、クラスターにコンシューマーがない場合は、メッセージは再分散されません。代わりに、それらが送信される元のノードに保管されます。
デフォルトのクラスター負荷分散ポリシーの変更
JBoss EAP 7 では、デフォルトのクラスター負荷分散ポリシーが変更になりました。
JBoss EAP 6 ではデフォルトの負荷分散ポリシーは STRICT
と似ており、レガシーの forward-when-no-consumers
パラメーターを true
に設定した場合と同様でした。JBoss EAP 7 では、デフォルトは ON_DEMAND
になり、レガシーの forward-when-no-consumers
パラメーターを false
に設定した場合と同様になります。これらの設定の詳細は、JBoss EAPConfiguring Messaging のCluster Connection Attributesを参照してください。
Messaging サブシステムの XML 設定
新しい messaging-activemq
サブシステムにより、XML の設定が大幅に変更になり、他の JBoss EAP サブシステムとより一貫性のある XML スキームが提供されるようになりました。
新しい messaging-activemq
サブシステムに準拠するために JBoss EAP messaging
サブシステムの XML 設定を変更しないでください。この代わりに、レガシーサブシステムの migrate
操作を呼び出してください。この操作は、実行の一部として新しい messaging-activemq
の XML 設定を書き込みます。
4.9.2. メッセージングデータの移行
以下の方法のいずれかを使用してメッセージングデータを以前のリリースの JBoss EAP から現在のリリースに移行します。
-
ファイルベースのメッセージングシステムでは、エクスポートおよびインポートメソッドを使用して メッセージングデータを JBoss EAP 6.4 および以前の JBoss EAP 7.x リリースから JBoss EAP 7.3 に移行できます。この方法では、これまでのリリースからメッセージングデータをエクスポートし、管理 CLI の
import-journal
操作を使用してインポートします。これは、ファイルベースのメッセージングシステムでのみ使用できることに注意してください。 - JMS ブリッジを設定 して、メッセージングデータを JBoss EAP 6.4 から JBoss EAP 7.3 に移行できます。この方法は、ファイルベースのメッセージングシステムと JDBC メッセージングシステムの両方に使用できます。
JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、JBoss EAP 7.0 以上のリリースではメッセージングデータの形式と場所が変更になりました。6.4 から 7.x リリースで変更になったメッセージングデータフォルダー名と場所の詳細は、メッセージングフォルダー名のマッピング を参照してください。
4.9.2.1. エクスポートおよびインポートを使用したメッセージングデータの移行
この方法では、以前のリリースのメッセージングデータを XML ファイルへエクスポートし、import-journal
操作を使用してそのファイルをインポートします。
メッセージングデータの XML ファイルへのエクスポート
- XML 形式のメッセージングデータのインポート
エクスポートおよびインポートメソッドは、JDBC ベースのジャーナルをストレージとして使用するシステム間でのメッセージングデータの移動には使用できません。
メッセージングデータの JBoss EAP 6.4 からのエクスポート
JMS サポートプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、JBoss EAP 7.0 以上のリリースではメッセージングデータの形式と場所が変更になりました。
JBoss EAP 6.4 からメッセージングデータをエクスポートする場合は、HornetQ の exporter
ユーティリティーを使用する必要があります。HornetQ exporter
ユーティリティーは、メッセージングデータを生成し、JBoss EAP 6.4 から XML 形式のファイルへエクスポートします。このコマンドでは、JBoss EAP 6.4 に同梱されている必須の HornetQ JAR へのパスを指定し、以前のリリースからの messagingbindings/
、messagingjournal/
、messagingpaging/
、および messaginglargemessages/
フォルダーへのパスを引数として渡し、エクスポートされる XML データを書き込む出力ファイルを指定する必要があります。
以下は HornetQ exporter
ユーティリティーで必要となる構文です。
$ java -jar -mp MODULE_PATH org.hornetq.exporter MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml
カスタムモジュールを作成し、パッチやアップグレードでインストールされた JAR を含む HornetQ JAR の正しいバージョンがロードされ、exporter
ユーティリティーで利用可能になるようにします。好みのエディターを使用して、EAP6_HOME/modules/org/hornetq/exporter/main/
ディレクトリーに新しい module.xml
ファイルを作成し、以下のコンテンツをコピーします。
<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter"> <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/> <properties> <property name="jboss.api" value="deprecated"/> </properties> <dependencies> <module name="org.hornetq"/> </dependencies> </module>
カスタムモジュールは modules/system/layers/base/
ディレクトリーではなく、modules/
ディレクトリー内に作成します。
以下の手順に従い、データをエクスポートします。
- JBoss EAP 6.4 サーバーを停止します。
- 上記の説明にあるようにカスタムモジュールを作成します。
以下のコマンドを実行してデータをエクスポートします。
$ java -jar jboss-modules.jar -mp modules/ org.hornetq.exporter standalone/data/messagingbindings/ standalone/data/messagingjournal/ standalone/data/messagingpaging standalone/data/messaginglargemessages/ > OUTPUT_DIRECTORY/OldMessagingData.xml
- コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。
- 使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの XML を検証します。
メッセージングデータの JBoss EAP 7.x からのエクスポート
以下の手順に従って、JBoss EAP 7.x からメッセージングデータをエクスポートします。
ターミナルを開き、JBoss EAP 7.x のインストールディレクトリーへ移動し、
admin-only
モードでサーバーを起動します。$ EAP_HOME/bin/standalone.sh -c standalone-full.xml --start-mode=admin-only
新しいターミナルを開き、JBoss EAP 7.x のインストールディレクトリーへ移動し、管理 CLI に接続します。
$ EAP_HOME/bin/jboss-cli.sh --connect
以下の管理 CLI コマンドを使用して、メッセージングジャーナルデータをエクスポートします。
/subsystem=messaging-activemq/server=default:export-journal()
- コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。
- 使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの XML を検証します。
XML 形式のメッセージングデータのインポート
以下のように、 import-journal
操作を使用して、XML ファイルを JBoss EAP 7.0 およびそれ以降のリリースにインポートします。
ターゲットサーバーによって一部のメッセージングタスクがすでに実行済みである場合は、インポートに失敗した場合にデータを損失しないようにするため、import-journal
操作の実行前にメッセージングフォルダーをバックアップしてください。詳細は、メッセージングフォルダーデータのバックアップ を参照してください。
- JBoss EAP 6.4 サーバーを 7.3 に移行する場合、サーバー設定の移行が完了してから 管理 CLI の migrate 操作 の使用または JBoss Server Migration Tool の実行を開始してください。このツールの設定および実行方法に関する詳細は、Using the JBoss Server Migration Tool を参照してください。
JMS クライアントが未接続の状態で、JBoss EAP 7.x サーバーを通常モードで起動します。
重要接続している JMS クライアントがない状態でサーバーを起動することが重要になります。これは、
import-journal
操作が JMS プロデューサーのように動作するからです。操作の実行中、メッセージは即座に使用できます。インポート中にこの操作に失敗し、JMS クライアントが接続状態である場合、JMS クライアントがメッセージの一部を消費済みである可能性があるため、復元することができません。新しいターミナルを開き、JBoss EAP 7.x のインストールディレクトリーへ移動し、管理 CLI に接続します。
$ EAP_HOME/bin/jboss-cli.sh --connect
以下の管理 CLI コマンドを使用して、メッセージングデータをインポートします。
/subsystem=messaging-activemq/server=default:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)
重要このコマンドは 1 度だけ実行してください。2 回以上実行するとメッセージが複製されます。
警告JBoss EAP 7.0 を使用している場合、Red Hat JBoss Enterprise Application Platform 7.0 Update 05 またはこれ以降の累積パッチを JBoss EAP インストールに適用し、大型メッセージの読み取り時に既知の問題が発生しないようにする必要があります。詳細は、JBEAP-4407 - Consumer crashes with IndexOutOfBoundsException when reading large messages from imported journal を参照してください。
この問題は JBoss EAP 7.1 以降には影響しません。
メッセージングデータのインポート失敗からの復元
import-journal
操作に失敗した場合、以下の手順に従って復元を行います。
- JBoss EAP 7.x サーバーをシャットダウンします。
- すべてのメッセージングジャーナルフォルダーを削除します。メッセージングジャーナルフォルダーのディレクトリーの場所を正しく判断する管理 CLI コマンドについては、メッセージングフォルダーデータのバックアップ を参照してください。
- インポートの前にターゲットサーバーのメッセージングデータをバックアップしたら、メッセージングフォルダーをバックアップした場所から前の手順で決定したメッセージングジャーナルディレクトリーにコピーします。
- 手順を繰り返して、XML でフォーマットされたメッセージングデータをインポート します。
4.9.2.2. JMS ブリッジを使用したメッセージングデータの移行
この方法では、JMS ブリッジを JBoss EAP 7.x サーバーに設定およびデプロイします。JMS ブリッジはメッセージを JBoss EAP 6.4 HornetQ のキューから JBoss EAP 7.x ActiveMQ Artemis のキューに移動します。
JMS ブリッジはソースの JMS キューまたはトピックからメッセージを消費し、通常は異なるサーバーにあるターゲット JMS キューまたはトピックへ送信します。JMS 1.1 に準拠する JMS サーバーの間でメッセージをブリッジするために使用できます。送信元および宛先の JMS リソースは、JNDI を使用してルックアップされ、JNDI ルックアップのクライアントクラスはモジュールでバンドルされる必要があります。モジュール名は JMS ブリッジ設定で宣言されます。
ここでは、メッセージングデータを JBoss EAP 6.4 から JBoss EAP 7.x に移動するためにサーバーを設定し、JMS ブリッジをデプロイする方法を説明します。
ソース JBoss EAP 6.4 サーバーの設定
- JBoss EAP 6.4 サーバーを停止します。
HornetQ のジャーナルおよび設定ファイルをバックアップします。
-
デフォルトでは、HornetQ ジャーナルは
EAP6_HOME/standalone/data/
ディレクトリーにあります。 - 各リリースにおけるメッセージングフォルダーのデフォルトの場所は、メッセージングフォルダー名のマッピング を参照してください。
-
デフォルトでは、HornetQ ジャーナルは
-
JMS メッセージが含まれる
InQueue
JMS キューが JBoss EAP 6.4 サーバーで定義されていることを確認してください。 messaging
サブシステムの設定に以下と似たRemoteConnectionFactory
のエントリーが含まれていることを確認してください。<connection-factory name="RemoteConnectionFactory"> <entries> <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/> </entries> ... </connection-factory>
エントリーが含まれていない場合は、以下の管理 CLI コマンドを使用して作成します。
/subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:add(factory-type=XA_GENERIC, connector=[netty], entries=[java:jboss/exported/jms/RemoteConnectionFactory],ha=true,block-on-acknowledge=true,retry-interval=1000,retry-interval-multiplier=1.0,reconnect-attempts=-1)
ターゲット JBoss EAP 7.x サーバーの設定
以前のリリースでは、JMS ブリッジ設定が HornetQ サーバーに接続するには、
org.hornetq
モジュールが必要です。このモジュールと直接の依存関係は JBoss EAP 7.x では存在しないため、以前のリリースから以下のモジュールをコピーする必要があります。org.hornetq
モジュールを JBoss EAP 7.x のEAP_HOME/modules/org/
ディレクトリーにコピーします。-
このモジュールにパッチを適用しなかった場合は、 JBoss EAP 6.4 サーバーから
EAP6_HOME/modules/system/layers/base/org/hornetq/
をコピーします。 -
このモジュールにパッチを適用した場合は、JBoss EAP 6.4 サーバーから
EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/hornetq/
をコピーします。
-
このモジュールにパッチを適用しなかった場合は、 JBoss EAP 6.4 サーバーから
JBoss EAP 7.x の
EAP_HOME/modules/org/hornetq/main/module.xml
ファイルから HornetQlib
の<resource-root>
を削除します。JBoss EAP 6.4 の
org.hornetq
モジュールにパッチを適用しなかった場合、ファイルから以下の行を削除します。<resource-root path="lib"/>
JBoss EAP 6.4 の
org.hornetq
モジュールにパッチを適用した場合、ファイルから以下の行を削除します。<resource-root path="lib"/> <resource-root path="../../../../../org/hornetq/main/lib"/>
警告HornetQ
lib
パスresource-root
の削除に失敗すると、ブリッジに障害が発生し、以下のエラーがログファイルに記録されます。2016-07-15 09:32:25,660 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "messaging-activemq"), ("jms-bridge" => "myBridge") ]) - failure description: "WFLYMSGAMQ0086: Unable to load module org.hornetq"
org.jboss.netty
モジュールを JBoss EAP 7.xEAP_HOME/modules/org/jboss/
ディレクトリーにコピーします。-
このモジュールにパッチを適用しなかった場合は、 JBoss EAP 6.4 サーバーから
EAP6_HOME/modules/system/layers/base/org/jboss/netty/
フォルダーをコピーします。 -
このモジュールにパッチを適用した場合は、 JBoss EAP 6.4 サーバーから
EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/jboss/netty
フォルダーをコピーします。
-
このモジュールにパッチを適用しなかった場合は、 JBoss EAP 6.4 サーバーから
JBoss EAP 6.4 サーバーから受信したメッセージを格納するために JSM キューを作成します。以下は、
MigratedMessagesQueue
JMS キューを作成してメッセージを受信する管理 CLI コマンドの例になります。jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue]
このコマンドにより、JBoss EAP 7 .x サーバーの
messaging-activemq
サブシステムに以下のデフォルトサーバー用のjms-queue
設定が作成されます。<jms-queue name="MigratedMessagesQueue" entries="jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue"/>
messaging-activemq
サブシステムのdefault
サーバーに以下と似たInVmConnectionFactory
connection-factory
の設定が含まれるようにしてください。<connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>
エントリーが含まれていない場合は、以下の管理 CLI コマンドを使用して作成します。
/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])
JBoss EAP 6 .4 サーバーで設定された
InQueue
JMS キューからメッセージを読み取る JMS ブリッジを作成およびデプロイし、JBoss EAP 7.x サーバーで設定されたMigratedMessagesQueue
に転送します。/subsystem=messaging-activemq/jms-bridge=myBridge:add(add-messageID-in-header=true,max-batch-time=100,max-batch-size=10,max-retries=-1,failure-retry-interval=1000,quality-of-service=AT_MOST_ONCE,module=org.hornetq,source-destination=jms/queue/InQueue,source-connection-factory=jms/RemoteConnectionFactory,source-context=[("java.naming.factory.initial"=>"org.wildfly.naming.client.WildFlyInitialContextFactory"),("java.naming.provider.url"=>"remote://127.0.0.1:4447")],target-destination=jms/queue/MigratedMessagesQueue,target-connection-factory=java:/ConnectionFactory)
これにより、以下の
jms-bridge
設定が JBoss EAP 7.x サーバーのmessaging-activemq
サブシステムに作成されます。<jms-bridge name="myBridge" add-messageID-in-header="true" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="1000" quality-of-service="AT_MOST_ONCE" module="org.hornetq"> <source destination="jms/queue/InQueue" connection-factory="jms/RemoteConnectionFactory"> <source-context> <property name="java.naming.factory.initial" value="org.wildfly.naming.client.WildFlyInitialContextFactory"/> <property name="java.naming.provider.url" value="remote://127.0.0.1:4447"/> </source-context> </source> <target destination="jms/queue/MigratedMessagesQueue" connection-factory="java:/ConnectionFactory"/> </jms-bridge>
-
セキュリティーが JBoss EAP 6.4 に設定されている場合、接続の作成時に JNDI ルックアップで使用される正しいユーザー名およびパスワードを指定する
source-context
が含まれるよう、JMS ブリッジ設定<source>
要素を設定する必要もあります。
メッセージングデータの移行
以下の設定に提供する情報が正しいことを確認します。
- キューおよびトピック名。
-
JNDI ルックアップの
java.naming.provider.url
。
- ターゲット JMS 宛先が JBoss EAP 7.x サーバーにデプロイされているようにしてください。
- JBoss EAP 6.4 サーバーと JBoss EAP 7.x サーバーを両方起動します。
4.9.2.3. メッセージングフォルダー名のマッピング
以下の表では、JBoss EAP の以前および現在のリリースで対応するメッセージングディレクトリーの名前を示しています。ディレクトリーは jboss.server.data.dir
ディレクトリーに相対的で、指定がない場合はデフォルトで EAP_HOME/standalone/data/
になります。
JBoss EAP 6.4 のディレクトリー名 | JBoss EAP 7.x のディレクトリー名 |
---|---|
|
|
|
|
|
|
|
|
大型のメッセージがない場合や、ページングが無効になっている場合は、messaginglargemessages/
および messagingpaging/
ディレクトリーが存在しないことがあります。
4.9.2.4. メッセージングフォルダーデータのバックアップ
ターゲットサーバーによってメッセージがすでに処理されている場合、ターゲットメッセージングフォルダーをバックアップしてから作業を開始した方がよいでしょう。メッセージングフォルダーのデフォルトの場所は EAP_HOME/standalone/data/activemq/
ですが、場所を設定できます。メッセージングデータの場所が分からない場合は、以下の管理 CLI コマンドを使用してメッセージングフォルダーの場所を探すことができます。
/subsystem=messaging-activemq/server=default/path=journal-directory:resolve-path /subsystem=messaging-activemq/server=default/path=paging-directory:resolve-path /subsystem=messaging-activemq/server=default/path=bindings-directory:resolve-path /subsystem=messaging-activemq/server=default/path=large-messages-directory:resolve-path
フォルダーの場所を特定したら、各フォルダーを安全にバックアップできる場所にコピーします。
4.9.3. JMS 宛先の移行
JBoss EAP 6 では、JMS 宛先キューは messaging
サブシステムの <hornetq-server>
要素下にある <jms-destinations>
要素に設定されました。
<hornetq-server> ... <jms-destinations> <jms-queue name="testQueue"> <entry name="queue/test"/> <entry name="java:jboss/exported/jms/queue/test"/> </jms-queue> </jms-destinations> ... </hornetq-server>
JBoss EAP 7 では、JMS 宛先キューは messaging-activemq
サブシステムのデフォルトの <server>
要素に設定されます。
<server name="default"> ... <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/> ... </server>
4.9.4. メッセージングインターセプターの移行
JBoss EAP 7 では、JMS メッセージングプロバイダーが HornetQ から ActiveMQ Artemis に変更されたため、メッセージングインターセプターが大幅に変更されました。
以前の JBoss EAP リリースに含まれていた HornetQ messaging
サブシステムでは、HornetQ インターセプターを JAR に追加し、HornetQ module.xml
ファイルを修正するというインストール方法が必要でした。
JBoss EAP 7 に含まれる messaging-activemq
サブシステムは、module.xml
ファイルの修正を必要としません。Apache ActiveMQ Artemis Interceptor インターフェイスを実装するユーザーインターセプタークラスは、どのサーバーモジュールからでもロードできるようになりました。インターセプターのロード先となるモジュールは、サーバー設定ファイルの messaging-activemq
サブシステムで指定します。
例: インターセプター設定
<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0"> <server name="default"> ... <incoming-interceptors> <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" /> <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" /> </incoming-interceptors> <outgoing-interceptors> <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" /> <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" /> </outgoing-interceptors> </server> </subsystem>
4.9.5. Netty サーブレット設定の変更
JBoss EAP 6 では、Netty サーブレットトランスポートと動作するようサーブレットエンジンを設定することができました。JBoss EAP 7 では、ビルトインメッセージングプロバイダーが HornetQ から ActiveMQ Artemis に変更になったため、この設定は使用できなくなりました。新しいビルトインメッセージング HTTP コネクターおよび HTTP アクセプターを使用するよう、サーブレット設定を変更する必要があります。
4.9.6. 汎用 JMS リソースアダプターの設定
サードパーティー JMS プロバイダーと使用するために汎用 JMS リソースアダプターを設定する方法は JBoss EAP 7 で変更になりました。詳細は、JBoss EAPConfiguring Messaging のDeploying a Generic JMS Resource Adapterを参照してください。
4.9.7. メッセージング設定の変更
JBoss EAP 7.0 では、check-for-live-server
属性を指定せずに replication-master
ポリシーを設定した場合のデフォルト値が false
でした。これは JBoss EAP 7.1 で変更になりました。check-for-live-server
属性のデフォルト値は true
です。
以下は、check-for-live-server
属性を指定せずに replication-master
を設定する管理 CLI コマンドの例になります。
/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=group1)
管理 CLI を使用してリソースを読み取ると、check-for-live-server
属性の値が true
に設定されることに注意してください。
/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-resource(recursive=true) { "outcome" => "success", "result" => { "check-for-live-server" => true, "cluster-name" => "my-cluster", "group-name" => "group1", "initial-replication-sync-timeout" => 30000L }, "response-headers" => {"process-state" => "reload-required"} }
4.9.8. リリース間の JMS シリアル化動作の変更
JMS 1.1 と JMS 2.0.0 では、javax.jms.JMSException
の serialVersionUID
が変更になりました。そのため、JMS 1.1 を使用して JMSException
のインスタンスまたは JMSException のサブクラスをシリアライズした場合、JMS 2.0.0 を使用してデシリアライズすることはできません。その逆も同様です。JMS 2.0.0 を使用して JMSException
のインスタンスをシリアライズした場合、JMS 1.1 を使用してデシリアライズすることはできません。両方の場合で以下のような例外が発生します。
javax.jms.JMSException: javax.jms.JMSException; local class incompatible: stream classdesc serialVersionUID = 8951994251593378324, local class serialVersionUID = 2368476267211489441
この問題は、JMS 2.0.1 メンテナンスリリースで修正されました。
以下の表は、各 JBoss EAP リリースの JMS 実装の詳細を表しています。
表4.4 各 JBoss EAP リリースの JMS 実装
JBoss EAP バージョン | JMS 実装 | JMS バージョン |
---|---|---|
6.4 | HornetQ | JMS 1.1 |
7.0 | Apache ActiveMQ Artemis | JMS 2.0.0 |
7.1 以上 | Apache ActiveMQ Artemis | JMS 2.0.1 以上 |
serialVersionUID
の互換性が維持されないと、以下の状況で移行時に問題が発生することがあります。
-
JBoss EAP 6.4 クライアントを使用して
JMSException
が含まれるメッセージを送信し、メッセージングデータを JBoss EAP 7.0 に移行した後、JBoss EAP 7.0 クライアントを使用してそのメッセージをデシリアライズしようとするとデシリアライズに失敗し、例外が発生します。これは、JMS 1.1 のserialVersionUID
は JMS 2.0.0 の serialVersionUID と互換性がないからです。 -
JBoss EAP 7.0 クライアントを使用して
JMSException
が含まれるメッセージを送信し、メッセージングデータを JBoss EAP 7.1 以上のリリースに移行した後、JBoss EAP 7.1 以上の クライアントを使用してそのメッセージをデシリアライズしようとするとデシリアライズに失敗し、例外が発生します。これは、JMS 2.0.0 のserialVersionUID
は JMS 2.0.1 以上の serialVersionUID と互換性がないからです。
JBoss EAP 6.4 クライアントを使用して JMSException
が含まれるメッセージを送信し、メッセージングデータを JBoss EAP 7.1 以上のリリースに移行した後、JBoss EAP 7.1 以上のクライアントを使用してそのメッセージをデシリアライズした場合、JMS 1.1 の serialVersionUID
は JMS 2.0.1 以上の serialVersionUID と互換性があるため、デシリアライズに成功します。
以下を実行してからメッセージングデータを移行することが推奨されます。
- JMSExceptions が含まれる JMS 1.1 のメッセージをすべて消費してからメッセージングデータを JBoss EAP 6.4 から JBoss EAP 7.0 へ移行します。
- JMSExceptions が含まれる JMS 2.0.0 のメッセージをすべて消費してからメッセージングデータを JBoss EAP 7.0 から JBoss EAP 7.1 以上のリリースへ移行します。