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-entriestrue に設定されていると、messaging-activemq サブシステムが legacy-connection-factory リソースを作成し、legacy-entriesjms-queue および jms-topic リソースに追加します。

ブール値の引数 add-legacy-entriesfalse に設定されていると、messaging-activemq サブシステムにはレガシーリソースが作成されず、レガシー JMS クライアントは JBoss EAP 7 サーバーと通信できません。これがデフォルト値になります。

前方互換性および後方互換性に関する詳細は、JBoss EAPConfiguring MessagingBackward 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-consumersfalse に設定され、クラスターにコンシューマーがない場合に、メッセージはクラスターのすべてのノードへ再分散されました。

この動作は JBoss EAP 7 では変更になりました。forward-when-no-consumersfalse に設定され、クラスターにコンシューマーがない場合は、メッセージは再分散されません。代わりに、それらが送信される元のノードに保管されます。

デフォルトのクラスター負荷分散ポリシーの変更

JBoss EAP 7 では、デフォルトのクラスター負荷分散ポリシーが変更になりました。

JBoss EAP 6 ではデフォルトの負荷分散ポリシーは STRICT と似ており、レガシーの forward-when-no-consumers パラメーターを true に設定した場合と同様でした。JBoss EAP 7 では、デフォルトは ON_DEMAND になり、レガシーの forward-when-no-consumers パラメーターを false に設定した場合と同様になります。これらの設定の詳細は、JBoss EAPConfiguring MessagingCluster 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 操作を使用してそのファイルをインポートします。

重要

エクスポートおよびインポートメソッドは、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/ ディレクトリー内に作成します。

以下の手順に従い、データをエクスポートします。

  1. JBoss EAP 6.4 サーバーを停止します。
  2. 上記の説明にあるようにカスタムモジュールを作成します。
  3. 以下のコマンドを実行してデータをエクスポートします。

    $ 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
  4. コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。
  5. 使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの XML を検証します。
メッセージングデータの JBoss EAP 7.x からのエクスポート

以下の手順に従って、JBoss EAP 7.x からメッセージングデータをエクスポートします。

  1. ターミナルを開き、JBoss EAP 7.x のインストールディレクトリーへ移動し、admin-only モードでサーバーを起動します。

    $ EAP_HOME/bin/standalone.sh -c standalone-full.xml --start-mode=admin-only
  2. 新しいターミナルを開き、JBoss EAP 7.x のインストールディレクトリーへ移動し、管理 CLI に接続します。

    $ EAP_HOME/bin/jboss-cli.sh --connect
  3. 以下の管理 CLI コマンドを使用して、メッセージングジャーナルデータをエクスポートします。

    /subsystem=messaging-activemq/server=default:export-journal()
  4. コマンド完了後に、ログにエラーや警告メッセージがないことを確認します。
  5. 使用中のオペレーティングシステムで利用可能なツールを使用して、生成された出力ファイルの XML を検証します。
XML 形式のメッセージングデータのインポート

以下のように、 import-journal 操作を使用して、XML ファイルを JBoss EAP 7.0 およびそれ以降のリリースにインポートします。

重要

ターゲットサーバーによって一部のメッセージングタスクがすでに実行済みである場合は、インポートに失敗した場合にデータを損失しないようにするため、import-journal 操作の実行前にメッセージングフォルダーをバックアップしてください。詳細は、メッセージングフォルダーデータのバックアップ を参照してください。

  1. JBoss EAP 6.4 サーバーを 7.3 に移行する場合、サーバー設定の移行が完了してから 管理 CLI の migrate 操作 の使用または JBoss Server Migration Tool の実行を開始してください。このツールの設定および実行方法に関する詳細は、Using the JBoss Server Migration Tool を参照してください。
  2. JMS クライアントが未接続の状態で、JBoss EAP 7.x サーバーを通常モードで起動します。

    重要

    接続している JMS クライアントがない状態でサーバーを起動することが重要になります。これは、import-journal 操作が JMS プロデューサーのように動作するからです。操作の実行中、メッセージは即座に使用できます。インポート中にこの操作に失敗し、JMS クライアントが接続状態である場合、JMS クライアントがメッセージの一部を消費済みである可能性があるため、復元することができません。

  3. 新しいターミナルを開き、JBoss EAP 7.x のインストールディレクトリーへ移動し、管理 CLI に接続します。

    $ EAP_HOME/bin/jboss-cli.sh --connect
  4. 以下の管理 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 操作に失敗した場合、以下の手順に従って復元を行います。

  1. JBoss EAP 7.x サーバーをシャットダウンします。
  2. すべてのメッセージングジャーナルフォルダーを削除します。メッセージングジャーナルフォルダーのディレクトリーの場所を正しく判断する管理 CLI コマンドについては、メッセージングフォルダーデータのバックアップ を参照してください。
  3. インポートの前にターゲットサーバーのメッセージングデータをバックアップしたら、メッセージングフォルダーをバックアップした場所から前の手順で決定したメッセージングジャーナルディレクトリーにコピーします。
  4. 手順を繰り返して、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 サーバーの設定
  1. JBoss EAP 6.4 サーバーを停止します。
  2. HornetQ のジャーナルおよび設定ファイルをバックアップします。

    • デフォルトでは、HornetQ ジャーナルは EAP6_HOME/standalone/data/ ディレクトリーにあります。
    • 各リリースにおけるメッセージングフォルダーのデフォルトの場所は、メッセージングフォルダー名のマッピング を参照してください。
  3. JMS メッセージが含まれる InQueue JMS キューが JBoss EAP 6.4 サーバーで定義されていることを確認してください。
  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 サーバーの設定
  1. 以前のリリースでは、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 7.x の EAP_HOME/modules/org/hornetq/main/module.xml ファイルから HornetQ lib<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.x EAP_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 フォルダーをコピーします。
  2. 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"/>
  3. 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])
  4. 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>
  5. セキュリティーが JBoss EAP 6.4 に設定されている場合、接続の作成時に JNDI ルックアップで使用される正しいユーザー名およびパスワードを指定する source-context が含まれるよう、JMS ブリッジ設定 <source> 要素を設定する必要もあります。
メッセージングデータの移行
  1. 以下の設定に提供する情報が正しいことを確認します。

    • キューおよびトピック名。
    • JNDI ルックアップの java.naming.provider.url
  2. ターゲット JMS 宛先が JBoss EAP 7.x サーバーにデプロイされているようにしてください。
  3. 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 のディレクトリー名

messagingbindings/

activemq/bindings/

messagingjournal/

activemq/journal/

messaginglargemessages/

activemq/largemessages/

messagingpaging/

activemq/paging/

注記

大型のメッセージがない場合や、ページングが無効になっている場合は、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 MessagingDeploying 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.JMSExceptionserialVersionUID が変更になりました。そのため、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 以上のリリースへ移行します。