メッセージングの設定

メッセージングシステムにより、異種システムを疎結合して、信頼性も高めることができます。Remote Procedure Call (RPC) パターンに基づいたシステムとは異なり、メッセージングシステムは、リクエストと応答の間に密接な関係がないパターンを渡す非同期メッセージを主に使用します。ほとんどのメッセージングシステムは、必要に応じてリクエスト応答モードもサポートできる柔軟性がありますが、これはメッセージングシステムの主要な機能ではありません。

メッセージングシステムは、そのコンシューマーからメッセージの送信者を切り離します。実際、メッセージの送信者とコンシューマーは完全に独立していて、相互に何も知らないため、柔軟な疎結合のシステムを作成できます。大企業は多くの場合、メッセージングシステムを使用して、異種システムを疎結合するメッセージバスを実装します。メッセージバスは、Enterprise Service Bus (ESB) の中核を形成することができます。メッセージバスを使用して共通点のないシステムを切り離すことで、システムを拡大し、より簡単に適応させることができます。また、不安定な相互依存性がないため、より柔軟に、新しいシステムを追加したり、古いシステムを廃止したできます。

メッセージングシステムには、信頼できるメッセージングを保証する配信保証、複数のメッセージの送信または消費を単一の作業単位として集約するトランザクション、メッセージがサーバーの障害や再起動に耐えられるようにする耐久性などの概念を組み込むこともできます。

ほとんどのメッセージングシステムがサポートするメッセージングスタイルには、ポイントツーポイントパターンとパブリッシュ/サブスクライブパターンの 2 種類があります。

Java Messaging Service (JMS) 2.0 は JSR 343 で定義されています。Jakarta EE と同等の仕様は Jakarta Messaging です。JMS は、ポイントツーポイントとパブリッシュ/サブスクライブの両方のメッセージングスタイルを提供する Java API です。JMS にはトランザクションの使用も組み込まれています。JMS は標準の回線形式を定義しないため、JMS プロバイダーのベンダーはすべて標準の API を使用しながら、クライアントとサーバー間の通信にさまざまな内部ネットワークプロトコルを使用できます。

JMS 宛先は、JMS 接続ファクトリーとともに、JMS 管理オブジェクトです。宛先は、JMS クライアントによってメッセージの生成と消費の両方に使用されます。JMS クライアントは宛先を使用して、メッセージの生成時にターゲットを、メッセージの消費時にメッセージのソースを指定できます。パブリッシュ/サブスクライブパターンを使用する場合、宛先はトピックと呼ばれます。ポイントツーポイントパターンを使用する場合、宛先はキューと呼ばれます。

アプリケーションは、サーバー側で設定され、通常 JNDI を介してアクセスされる多くの異なる JMS 宛先を使用できます。

Apache ActiveMQ Artemis は非同期メッセージングシステムのオープンソースプロジェクトです。高性能で、埋め込み可能であり、クラスター化されていて、複数のプロトコルをサポートします。JBoss EAP 7 は Apache ActiveMQ Artemis を JMS ブローカーとして使用し、messaging-activemq サブシステムを使用して設定されます。これは HornetQ ブローカーを完全に置き換えますが、JBoss EAP 6 とのプロトコル互換性を維持します。

コアの ActiveMQ Artemis は JMS に依存せず、コア API と呼ばれる非 JMS API を提供します。ActiveMQ Artemis は、ファサードレイヤーを使用してコア API 上で JMS セマンティクスを実装する JMS クライアント API も提供します。基本的に、JMS のやり取りは、JMS クライアント API を使用してクライアント側のコア API 操作に変換されます。そこから、コアクライアント API および Apache ActiveMQ Artemis の回線形式を使用してすべての操作を送信します。サーバー自体はコア API のみを使用します。コア API とその概念の詳細は、ActiveMQ Artemis のドキュメント を参照してください。

JMS 宛先が Apache ActiveMQ Artemis アドレスにマップされる方法を簡単に説明します。

Apache ActiveMQ Artemis コアは JMS に依存しません。JMS トピックの概念はありません。JMS トピックは、0 個以上のキューがバインドされたアドレス (トピック名) としてコアに実装されます。このアドレスにバインドされる各キューが、トピックサブスクリプションを表します。同様に、JMS キューは、JMS キューを表す単一のキューがバインドされるアドレス (JMS キュー名) として実装されます。

通常、すべての JMS キューは、コアキュー名の先頭に文字列 jms.queue が付加されたコアキューにマップさ れます。たとえば、orders.europe の名前を持つ JMS キューが、jms.queue.orders.europe の名前でコアキューにマップされます。コアキューがバインドされるアドレスもコアキュー名で指定されます。

JMS トピックの場合、サブスクリプションを表すキューがバインドされるアドレスは、文字列 jms.topic. を JMS トピックの名前の先頭に付加して指定されます。たとえば、news.europe という名前の JMS トピックは、コアアドレス jms.topic.news.europe にマップされます。

つまり、orders.europe という名前の JMS キューへの JMS メッセージを送信する場合は、サーバーを介してアドレス jms.queue.orders.europe にバインドされるコアキューにルーティングされます。news.europe という名前の JMS トピックへの JMS メッセージを送信する場合は、サーバーを介してアドレス jms.topic.news.europe にバインドされるコアキューにルーティングされます。

名前が orders.europe の JMS キューの設定を行うには、対応するコアキュー jms.queue.orders.europe を設定する必要があります。

<!-- expired messages in JMS Queue "orders.europe" will be sent to the JMS Queue "expiry.europe" -->
<address-setting match="jms.queue.orders.europe">
   <expiry-address>jms.queue.expiry.europe</expiry-address>
   ...
</address-setting>

helloworld-mdb クイックスタートでは単純なメッセージ駆動 Bean を使用して、基本的な Jakarta EE メッセージング機能を示します。JBoss EAP メッセージングサーバーに用意されている機能を知るには、クイックスタートを起動して 基本設定を確認 しながら実行する方法が非常に優れています。

helloworld-mdb クイックスタートのビルドとデプロイ

helloworld-mdb クイックスタートをビルドし、デプロイする方法については、クイックスタートで提供される README.md ファイルの手順を参照してください。messaging-activemq サブシステムを含む full 設定を指定する JBoss EAP サーバーを開始する必要があります。異なる設定ファイルを使用して JBoss EAP を開始する方法は、README.md ファイルまたは JBoss EAP 設定ガイド を参照してください。

messaging-activemq サブシステムのデフォルト設定は、JBoss EAP サーバーを full または full-ha 設定で開始するときに含まれます。full-ha オプションには、クラスターリング や 高可用性 などの機能の高度な設定が含まれます。

必須ではありませんが、helloworld-mdb クイックスタートを作業例として使用 して、この設定の概要と一緒に実行することが推奨されます。

messaging-activemq サブシステムで使用できるすべての設定については、EAP_HOME/docs/schema/ ディレクトリーにあるスキーマ定義を参照するか、以下のように、管理 CLI からサブシステムで read-resource-description 操作を実行します。

/subsystem=messaging-activemq:read-resource-description(recursive=true)

サーバー設定ファイルの以下のエクステンションは、JBoss EAP に対して、そのランタイムの一部として messaging-activemq サブシステムを含めるように指示するものです。

<extensions>
  ...
  <extension module="org.wildfly.extension.messaging-activemq"/>
  ...
</extensions>

messaging-activemq サブシステムの設定は <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0"> 要素内に含まれます。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
    <server name="default">
        <cluster password="${jboss.messaging.cluster.password:CHANGE ME!!}"/>
        <security-setting name="#">
            <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
        </security-setting>
        <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="1000"/>
        <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
        <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
            <param name="batch-delay" value="50"/>
        </http-connector>
        <in-vm-connector name="in-vm" server-id="0"/>
        <http-acceptor name="http-acceptor" http-listener="default"/>
        <http-acceptor name="http-acceptor-throughput" http-listener="default">
            <param name="batch-delay" value="50"/>
            <param name="direct-deliver" value="false"/>
        </http-acceptor>
        <in-vm-acceptor name="in-vm" server-id="0"/>
        <broadcast-group name="bg-group1" connectors="http-connector" jgroups-cluster="activemq-cluster"/>
        <discovery-group name="dg-group1" jgroups-cluster="activemq-cluster"/>
        <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/>
        <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
        <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
        <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
        <connection-factory name="RemoteConnectionFactory" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
        <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
    </server>
</subsystem>

接続ファクトリー

メッセージングクライアントは JMS ConnectionFactory オブジェクトを使用してサーバーに接続します。デフォルトの JBoss EAP 設定は複数の接続ファクトリーを定義します。in-vm、http、および pooled 接続の <connection-factory> があることに留意します。

  <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
  <connection-factory name="RemoteConnectionFactory" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
  <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>

詳細は、接続ファクトリーの設定 のセクションを参照してください。

コネクターとアクセプター

各 JMS 接続ファクトリーはコネクターを使用して、クライアントプロデューサーまたはコンシューマーからメッセージングサーバーへの JMS 対応通信を有効にします。コネクターオブジェクトは、メッセージングサーバーに接続するために使用されるトランスポートとパラメーターを定義します。それに対応するのが、メッセージングサーバーが受け入れる接続タイプを識別するアクセプターオブジェクトです。

デフォルトの JBoss EAP 設定は複数のコネクターとアクセプターを定義します。

<http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
<http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
  <param name="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0"/>

<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
  <param name="batch-delay" value="50"/>
  <param name="direct-deliver" value="false"/>
</http-acceptor>

詳細については、アクセプターとコネクター のセクションを参照してください。

ソケットバインディンググループ

デフォルトのコネクターの socket-binding 属性は、http という名前のソケットバインディングを参照します。JBoss EAP は標準の Web ポートで受信リクエストを多重化できるため、http コネクターが使用されます。

この socket-binding は、設定ファイルの他の場所の <socket-binding-group> セクションの一部として見つけることができます。http および https ソケットバインディングの設定が、<socket-binding-groups> 要素内でどのように表示されているかに注目してください。

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
   ...
  <socket-binding name="http" port="${jboss.http.port:8080}"/>
  <socket-binding name="https" port="${jboss.https.port:8443}"/>
   ...
</socket-binding-group>

ソケットバインディングに関する詳細は、JBoss EAP設定ガイドの ソケットバインディングの設定 を参照してください。

メッセージングセキュリティー

messaging-activemq サブシステムには、JBoss EAP の初回インストール時に単一の security-setting 要素が含まれます。

<security-setting name="#">
  <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>

これは、ワイルドカード # で示され、ロール guest が指定されたすべてのユーザーが、サーバー上の任意のアドレスにアクセスできることを宣言します。ワイルドカード構文の詳細は、アドレス設定の設定 を参照してください。

接続先およびリモート接続のセキュリティー保護の詳細は、メッセージングセキュリティーの設定 を参照してください。

メッセージング宛先

full および full-ha 設定には、JBoss EAP が期限切れのメッセージまたは適切な宛先にルーティングできないメッセージを保持するのに使用できる 2 つの有用なキューが含まれます。

<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>

以下のメソッドのいずれかを使用して、JBoss EAP に独自のメッセージング宛先を追加できます。

詳細は、メッセージング宛先の設定 を参照してください。

JMS キューを追加するには、管理 CLI から次の jms-queue コマンドを使用します。

jms-queue add --queue-address=myQueue --entries=[queue/myQueue jms/queue/myQueue java:jboss/exported/jms/queue/myQueue]

entries 属性は、複数の JNDI 名が単一スペースで区切られたリストであることに注意してください。JNDI 名のリストが角括弧 [] を使用して囲んであることにも留意します。queue-address はルーティング設定を提供し、entries はクライアントがキューを検索するために使用できる JNDI 名のリストを提供します。

キューの属性の読み取り

管理 CLI で jms-queue コマンドを使用してキュー の設定を読み取ることができます。

jms-queue read-resource --queue-address=myQueue

または、管理 CLI を使用して messaging-activemq サブシステムにアクセスすることで、キューの設定を読み取ることもできます。

/subsystem=messaging-activemq/server=default/jms-queue=myQueue:read-resource()
{
    "outcome" => "success",
    "result" => {
        "durable" => true,
        "entries" => ["queue/myQueue jms/queue/myQueue java:jboss/exported/jms/queue/myQueue"],
        "legacy-entries" => undefined,
        "selector" => undefined
    }
}

jms-queue の属性

管理 CLI は、以下のコマンドを実行すると、jms-queue 設定要素のすべての属性を表示します。

/subsystem=messaging-activemq/server=default/jms-queue=*:read-resource-description()

以下の表は、jms-queue のすべての属性を示します。

トピックの追加や読み取りは、キューの追加によく似ています。

jms-topic add --topic-address=myTopic --entries=[topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic]

トピック属性の読み取り

トピック属性の読み取りの構文も、キューに使用される構文に似ています。

jms-topic read-resource --topic-address=myTopic

entries
  topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic
legacy-entries=n/a

/subsystem=messaging-activemq/server=default/jms-topic=myTopic:read-resource
{
    "outcome" => "success",
    "result" => {
        "entries" => ["topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic"],
        "legacy-entries" => undefined
    }
}

jms-topic の属性

管理 CLI は、以下のコマンドを実行すると、jms-topic 設定要素のすべての属性を表示します。

/subsystem=messaging-activemq/server=default/jms-topic=*:read-resource-description()

以下の表は、jms-topic の属性を示します。

リモートクライアントが検索できるようにするため、キューまたはトピックは java:jboss/exported 名前空間にバインドする必要があります。クライアントは、ルックアップを行うときに java:jboss/exported/ の後にテキストを使用する必要があります。たとえば、testQueue という名前のキューは、その entries にリスト jms/queue/test java:jboss/exported/jms/queue/test が含まれます。testQueue にメッセージを送信するリモートクライアントは、文字列 jms/queue/test を使用してキューを検索します。一方、ローカルクライアントは java:jboss/exported/jms/queue/test、java:jms/queue/test、またはさらに単純な jms/queue/test を使用して検索できます。

管理 CLI のヘルプ

--help --commands フラグを使用すると、jms-queue コマンドと jms-topic コマンドに関する詳細情報を確認できます。

jms-queue --help --commands

jms-topic --help --commands

ワイルドカードを使用すると、多数のシステムがアスタリスク記号 * を使用して単一のクエリーで複数のファイルまたは文字列を照合するのと同様に、単一のステートメントで類似したアドレスを照合できます。以下の表は、<address-setting> の定義に使用できる特殊文字のリストです。

以下の表の例は、ワイルドカードを使用してアドレスセットを照合する方法を示しています。

初期状態では、JBoss EAP には messaging-activemq サブシステムの設定の一部として単一の address-setting 要素が含まれています。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
      ...
      <address-setting
        name="#"
        dead-letter-address="jms.queue.DLQ"
        expiry-address="jms.queue.ExpiryQueue"
        max-size-bytes="10485760"
        page-size-bytes="2097152"
        message-counter-history-day-limit="10" />
      ...
  </server>
</subsystem>

管理 CLI を使用したアドレス設定の設定

アドレス設定は、管理 CLI または管理コンソールを使用して設定できますが、管理 CLI の方が編集用に多くの設定属性が公開されています。属性の詳細リストは、本ガイドの付録の アドレス設定の属性 を参照してください。

新しい address-setting の追加

必要に応じて add 操作を使用して新規アドレス設定を作成します。管理 CLI セッションのルートからこのコマンドを実行できます。以下の例では、名前を指定した新しいパターンが作成されます。address-setting の設定属性を含めることができます。以下では、news.europe.# に一致する新しい address-setting が作成され、その dead-letter-address 属性が、あらかじめ作成されたキュー DLQ.news に設定されます。スタンドアロンサーバーと、full プロファイルを使用した管理対象サーバードメインの両方の例をそれぞれ示します。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:add(dead-letter-address=DLQ.news)

/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:add(dead-letter-address=DLQ.news)

address-setting 属性の編集

write-attribute 操作を使用して新しい値を属性に書き込みます。タブ補完を使用すると、入力時のコマンド文字列の補完に役立つほか、利用可能な属性を明らかにできます。以下の例は、max-bearery-attempts の値を 10 に更新します。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:write-attribute(name=max-delivery-attempts,value=10)

/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:write-attribute(name=max-delivery-attempts,value=10)

address-setting 属性の読み取り

値が変更されたことを確認するには、include-runtime=true パラメーターを指定して read-resource 操作を実行し、サーバーモデルでアクティブな現在の値をすべて開示します。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:read-resource(include-runtime=true)

/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:read-resource(include-runtime=true)

管理コンソールを使用したアドレス設定の設定

以下の手順に従うと、管理コンソールを使用してアドレス設定の作成およびレビューを実行できます。

news.europe.# などの新しいパターンを追加する場合、Pattern フィールドは address-setting 要素の name 属性を参照します。管理 CLI を使用して属性の読み取り/書き込みを行う際にこの値を入力します。

管理コンソールを使用する場合は、dead-letter-address、expiry-address、redelivery-delay、および max-delivery-attempts 属性のみを編集できます。その他の属性は、管理 CLI を使用して設定する必要があります。

メッセージングサーバーのグローバルリソースの使用設定

address-setting 要素の 3 つの属性により、メッセージングサーバーのグローバルリソースの使用を制御できます。

last-value キューは、明確に定義された last-value プロパティーと同じ値のメッセージが新たにキューに入れられると、メッセージをすべて破棄する特別なキューです。つまり、last-value キューは最後の値のみを保持します。last-value キューの代表的な応用例には、特定の株式の最終株価のみに関心がある場合の株価があります。

last-value キューの設定

last-value キューは、address-setting 設定要素内に定義されます。

<address-setting name="jms.queue.lastValueQueue" last-value-queue="true" />

管理 CLI を使用して、特定の address-setting の last-value-queue の値を読み取ります。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#:read-attribute(name=last-value-queue)
{
    "outcome" => "success",
    "result" => false
}

last-value-queue に許可される値は true または false です。管理 CLI を使用して、次のようにいずれかの値を設定します。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#:write-attribute(name=last-value-queue,value=true)

/subsystem=messaging-activemq/server=default/address-setting=news.asia.#:write-attribute(name=last-value-queue,value=false)

last-value プロパティーの使用

最終値の特定に使用されるプロパティー名は _AMQ_LVQ_NAME (またはコア API の定数 Message.HDR_LAST_VALUE_NAME) です。以下の Java コードで last-value プロパティーの使用方法を示します。

TextMessage message = session.createTextMessage("My 1st message with the last-value property set");
message.setStringProperty("_AMQ_LVQ_NAME", "MY_MESSAGE");
producer.send(message);

message = session.createTextMessage("My 2nd message with the last-value property set");
message.setStringProperty("_AMQ_LVQ_NAME", "MY_MESSAGE");
producer.send(message);

TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
System.out.format("Received message: %s\n", messageReceived.getText());

上記の例では、両方のメッセージが _AMQ_LVQ_NAME を "MY_MESSAGE" に設定しており、最初のメッセージの後に 2 番目のメッセージがキューで受信されたため、クライアントの出力は "My 2nd message with the last-value property set" になります。

メッセージングサーバーへのリモート接続のセキュリティーを保護する他に、特定の宛先のセキュリティーを設定することもできます。この設定をする場合は、security-setting 設定要素を使用してセキュリティー制約を追加します。JBoss EAP メッセージングには、以下の管理 CLI コマンドの出力のような security-setting がデフォルトで設定されています。

/subsystem=messaging-activemq/server=default:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        ....
        "security-setting" => {"#" => {"role" => {"guest" => {
            "consume" => true,
            "create-durable-queue" => false,
            "create-non-durable-queue" => true,
            "delete-durable-queue" => false,
            "delete-non-durable-queue" => true,
            "manage" => false,
            "send" => true
        }}}}
    }
}

security-setting オプションでは、name フィールドにワイルドカードを使用して、セキュリティー制約を適用する宛先を指定できます。# 1 つでアドレスが任意であることを表します。セキュリティー制約でのワイルドカードの使用に関する詳細は、アドレスのロールベースのセキュリティー を参照してください。

/subsystem=messaging-activemq/server=default/security-setting=news.europe.#:add()
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default/security-setting=news.europe.#/role=dev:add(consume=true,delete-non-durable-queue=true,create-non-durable-queue=true,send=true)
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default/security-setting=news.europe.#/role=admin:add(manage=true,create-durable-queue=true,delete-durable-queue=true)
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=security-setting,recursive=true)
{
    "outcome" => "success",
    "result" => {
        "#" => {"role" => {"guest" => {
            "consume" => true,
            "create-durable-queue" => false,
            "create-non-durable-queue" => true,
            "delete-durable-queue" => false,
            "delete-non-durable-queue" => true,
            "manage" => false,
            "send" => true
        }}},
        "news.europe.#" => {"role" => {
            "dev" => {
                "consume" => true,
                "create-durable-queue" => false,
                "create-non-durable-queue" => true,
                "delete-durable-queue" => false,
                "delete-non-durable-queue" => true,
                "manage" => false,
                "send" => true
            },
            "admin" => {
                "consume" => false,
                "create-durable-queue" => true,
                "create-non-durable-queue" => false,
                "delete-durable-queue" => true,
                "delete-non-durable-queue" => false,
                "manage" => true,
                "send" => false
            }
        }}
    }

ObjectMessage には潜在的に危険性があるオブジェクトを含めることができます。そのため、ActiveMQ Artemis では信頼できるパッケージやクラスと信頼できないパッケージやクラスを管理するシンプルなクラスのフィルタリングメカニズムを提供します。信頼できるパッケージのクラスを持つオブジェクトをホワイトリストに追加することで、問題なくデシリアライズできることを示すことができます。信頼できないパッケージのクラスを持つオブジェクトはブラックリストに追加することで、デシリアライズされないようにすることができます。

ActiveMQ Artemis は以下のようにデシリアライズするオブジェクトをフィルターにかけます。

オブジェクトのフルネームがリスト内のエントリーのいずれかと完全に一致する場合、そのパッケージがリストにあるエントリーのいずれかと一致する場合、またはこれがリスト内にあるエントリーのいずれかのサブパッケージである場合、オブジェクトは一致すると見なされます。

deserialization-white-list 属性と deserialization- black-list 属性を使用して、connection-factory と pooled-connection-factory でデシリアライズできるオブジェクトを指定できます。deserialization-white-list 属性は、デシリアライズできるクラスまたはパッケージのリストを定義するために使用されます。deserialization-black-list 属性は、デシリアライズできないクラスまたはパッケージのリストを定義するために使用されます。

以下のコマンドにより、デフォルトサーバーの RemoteConnectionFactory 接続ファクトリーのブラックリストおよび activemq-ra プールされた接続ファクトリーのホワイトリストが作成されます。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=deserialization-black-list,value=[my.untrusted.package,another.untrusted.package])
/subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=deserialization-white-list,value=[my.trusted.package])

これらのコマンドにより、messaging-activemq サブシステムで以下の設定が生成されます。

<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" deserialization-black-list="my.untrusted.package another.untrusted.package"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" deserialization-white-list="my.trusted.package" transaction="xa"/>

接続ファクトリーとプールされた接続ファクトリーの詳細は、本ガイドの 接続ファクトリーの設定 を参照してください。

また、アクティベーションプロパティーを設定して、MDB でデシリアライズできるオブジェクトを指定することもできます。deserializationWhiteList プロパティーは、デシリアライズできるクラスまたはパッケージのリストを定義するために使用されます。deserializationBlackList プロパティーは、デシリアライズできないクラスまたはパッケージのリストを定義するために使用されます。アクティベーションプロパティーの詳細は、JBoss EAP Developing EJB Applicationsの Configuring MDBs Using a Deployment Descriptor を参照してください。

security-invalidation-interval サブシステムのサーバーの messaging-activemq 属性は、アクションを再認証する必要がある前に承認がキャッシュされる期間を決定します。

システムがアドレスでアクションの実行をユーザーに承認すると、承認はキャッシュされます。次に同じユーザーが同じアドレスで同じアクションを実行すると、システムはキャッシュされた承認をアクションに使用します。

たとえば、ユーザー admin はメッセージをアドレス news に送信しようとします。システムはアクションを承認し、承認をキャッシュします。次に 管理者 がメッセージを送信しようとすると、システム はキャッシュされた承認を使用します。

キャッシュされた承認が無効化間隔で指定された時間内に再度使用されない場合、承認はキャッシュから消去されます。システムは、要求されたアドレスで要求されたアクションを実行するためにユーザーを再認証する必要があります。

インストール後に、JBoss EAP では、デフォルト値が 10000 ミリ秒 (10 秒) となります。

/subsystem=messaging-activemq/server=default:read-attribute(name=security-invalidation-interval)
{
    "outcome" => "success",
    "result" => 10000L
}

security-invalidation-interval 属性は設定可能です。たとえば、以下のコマンドは間隔を 60000 ミリ秒 (60 秒または 1 分) に更新します。

/subsystem=messaging-activemq/server=default:write-attribute(name=security-invalidation-interval,value=60000)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

設定変更を有効にするには、サーバーをリロードする必要があります。

属性を読み取ると、新しい結果が表示されます。

/subsystem=messaging-activemq/server=default:read-attribute(name=security-invalidation-interval)
{
    "outcome" => "success",
    "result" => 60000L
}

JBoss EAP の設定では、3 つの主要なタイプのアクセプターとコネクターが定義されています。

in-vm: In-vm は Intra Virtual Machine の省略形です。クライアントおよびサーバーの両方が同じ JVM で実行されている場合は、このコネクタータイプを使用します (例: Message Driven bean (MDB) が JBoss EAP の同じインスタンスで実行されている場合)。

http: クライアントとサーバーが異なる JVM で実行されている場合に使用します。undertow サブシステムのデフォルトのポートである 8080 を使用すると、HTTP による多重メッセージ通信が可能になります。Red Hat は、クライアントおよびサーバーが異なる JVM で実行されている場合、特にクラウド環境におけるポート管理などを考慮して、http コネクターを使用することを推奨します。

remote: リモートトランスポートは、クライアントとサーバーが異なる JVM で実行されている場合に、ネイティブ TCP 通信に使用される Netty ベースのコンポーネントです。このコンポーネントは http を使用できない場合の代替手段となります。

クライアントは、いずれかのサーバーのアクセプターと互換性のあるコネクターを使用する必要があります。たとえば、in-vm-connector のみが in-vm-acceptor に接続でき、http-connector のみが http-acceptor に接続できます。

管理 CLI の read-children-attributes 操作を使用すると、指定のアクセプターまたはコネクタータイプの属性を一覧表示できます。たとえば、デフォルトのメッセージングサーバーのすべての http-connectors の属性を表示するには、以下の入力を行います。

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=http-connector,include-runtime=true)

同様のコマンドを使用して、すべての http-acceptors の属性を読み込みます。

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=http-acceptor,include-runtime=true)

他のアクセプターおよびコネクタータイプは同じ構文に従います。child-type で remote-connector や in-vm-acceptor などのアクセプタータイプまたはコネクタータイプを指定するだけです。

アクセプターは、JBoss EAP 統合メッセージングサーバーによって許可される接続のタイプを定義します。サーバーごとに任意の数のアクセプターを定義できます。以下の設定例はデフォルトの full-ha 設定プロファイルを修正したもので、各アクセプタータイプの例を示しています。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <http-acceptor name="http-acceptor" http-listener="default"/>
    <remote-acceptor name="legacy-messaging-acceptor" socket-binding="legacy-messaging"/>
    <in-vm-acceptor name="in-vm" server-id="0"/>
    ...
  </server>
</subsystem>

上記の設定では、http-acceptor は JBoss EAP のデフォルトの http ポート 8080 をリッスンする Undertow のデフォルト http-listener を使用しています。http-listener は undertow サブシステムで定義されます。

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
  ...
  <server name="default-server">
    <http-listener name="default" redirect-socket="https" socket-binding="http"/>
    ...
  </server>
  ...
</subsystem>

また、上記の remote-acceptor が legacy-messaging という名前の socket-binding を使用する仕組みに注意してください。これは、サーバーのデフォルトの socket-binding-group の一部として、設定の後半で定義されています。

<server xmlns="urn:jboss:domain:8.0">
  ...
  <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
      ...
      <socket-binding name="legacy-messaging" port="5445"/>
      ...
  </socket-binding-group>
</server>

この例では、legacy-messaging socket-binding は JBoss EAP をポート 5445 にバインドしており、上記の remote-acceptor がレガシークライアントで使用するために messaging-activemq サブシステムの代わりにポートを要求しています。

最後に、in-vm-acceptor は server-id 属性に一意の値を使用しており、このサーバーインスタンスを同じ JVM で実行されている他のサーバーと区別することができます。

コネクターは、統合 JBoss EAP メッセージングサーバーに接続する方法を定義しており、クライアントで接続するために使用されます。

コネクターは実際にはクライアントで使用されるのに、なぜサーバーで定義するのかとお考えになるかもしれません。これには、以下のような理由があります。

サーバーごとに任意の数のコネクターを定義できます。以下の設定例は full-ha 設定プロファイルをベースとしたもので、各タイプのコネクターが含まれています。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http" server-name="messaging-server-1"/>
    <remote-connector name="legacy-remoting-connector" socket-binding="legacy-remoting"/>
    <in-vm-connector name="in-vm" server-id="0"/>
    ...
  </server>
</subsystem>

full-ha プロファイルの http-acceptor と同様に、http-connector は undertow サブシステムで定義されたデフォルトの http-listener を使用します。endpoint 属性は、接続する http-acceptor を宣言します。この場合、コネクターはデフォルトの http-acceptor に接続します。

JBoss EAP 7.1 では、http-connector に新しい server-name 属性が導入されました。この新しい属性はオプションですが、複数の ActiveMQ Artemis インスタンスを実行しているリモートサーバーの適切な http-acceptor に接続できることが要求されます。この属性が定義されていない場合、値は実行時に解決され、コネクターが定義されている親 ActiveMQ Artemis サーバーの名前になります。

また、remote-connector は remote-acceptor のカウンターパートとして同じ socket-binding を参照します。最後に、in-vm-connector と in-vm-acceptor は同じサーバーインスタンス内で実行しているため、server-id に同じ値を使用します。

AMQ121005: Invalid "host" value "0.0.0.0" detected for "connector" connector. Switching to <HOST_NAME>. If this new address is incorrect please manually configure the connector to use the proper one.

コネクターとアクセプターには複数の設定オプションがあります。こうしたオプションは、設定の子要素 <param> として表示されます。<param> の各要素には、コネクターまたはアクセプターをインスタンス化するデフォルトの Netty ベースのファクトリークラスによって認識され、使用される name と value の属性ペアが含まれています。

管理 CLI では、各リモートコネクターまたはアクセプターの要素に、パラメーターの名前と値のペアの内部マップが含まれます。たとえば、myRemote という名前の remote-connector に新しい param を追加するには、以下のコマンドを使用します。

/subsystem=messaging-activemq/server=default/remote-connector=myRemote:map-put(name=params,key=foo,value=bar)

同様の構文を使用してパラメーター値を取得します。

/subsystem=messaging-activemq/server=default/remote-connector=myRemote:map-get(name=params,key=foo)
{
    "outcome" => "success",
    "result" => "bar"
}

また、アクセプターまたはコネクターを作成する際に、以下の例のようにパラメーターを含めることもできます。

/subsystem=messaging-activemq/server=default/remote-connector=myRemote:add(socket-binding=mysocket,params={foo=bar,foo2=bar2})

クライアントをサーバーに接続する場合は、適切なコネクターが必要です。これには 2 つの方法があります。サーバーに設定され、JNDI ルックアップから取得できる ConnectionFactory を使用することができます。または、ActiveMQ Artemis コア API を使用して、クライアント側で ConnectionFactory 全体を設定することもできます。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    [...]
    <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor" />
    <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
      <param name="batch-delay" value="50"/>
    </http-connector>
    <in-vm-connector name="in-vm" server-id="0"/>
    [...]
    <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory" />
    <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
    [...]
    </server>
</subsystem>

<connection-factory
  name="InVmConnectionFactory"
  entries="java:/ConnectionFactory"
  connectors="in-vm" />

InitialContext ctx = new InitialContext();
ConnectionFactory cf = (ConnectionFactory)ctx.lookup("ConnectionFactory");
Connection connection = cf.createConnection();

<connection-factory
  name="RemoteConnectionFactory"
  scheduled-thread-pool-max-size="10"
  entries="java:jboss/exported/jms/RemoteConnectionFactory"
  connectors="http-connector"/>

final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
env.put(Context.PROVIDER_URL, "http-remoting://remotehost:8080");
InitialContext remotingCtx = new InitialContext(env);
ConnectionFactory cf = (ConnectionFactory) remotingCtx.lookup("jms/RemoteConnectionFactory");

<dependencies>
  <dependency>
    <groupId>org.wildfly</groupId>
    <artifactId>wildfly-jms-client-bom</artifactId>
    <type>pom</type>
  </dependency>
</dependencies>

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(new TransportConfiguration(InVMConnectorFactory.class.getName()));

ClientSessionFactory factory =  locator.createClientSessionFactory();

ClientSession session = factory.createSession();

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(
  new TransportConfiguration( InVMConnectorFactory.class.getName()));

// In this simple example, we just use one session for both
// producing and consuming
ClientSessionFactory factory =  locator.createClientSessionFactory();
ClientSession session = factory.createSession();

// A producer is associated with an address ...
ClientProducer producer = session.createProducer("example");
ClientMessage message = session.createMessage(true);
message.getBodyBuffer().writeString("Hello");

// We need a queue attached to the address ...
session.createQueue("example", "example", true);

// And a consumer attached to the queue ...
ClientConsumer consumer = session.createConsumer("example");

// Once we have a queue, we can send the message ...
producer.send(message);

// We need to start the session before we can -receive- messages ...
session.start();
ClientMessage msgReceived = consumer.receive();

System.out.println("message = " + msgReceived.getBodyBuffer().readString());

session.close();

JBoss EAP をロードバランサーとして使用する場合、クライアントは静的 Undertow HTTP ロードバランサーまたは mod_cluster ロードバランサーの内側でメッセージングサーバーを呼び出します。

静的ロードバランサーを使用してメッセージングサーバーを呼び出すメッセージングクライアントをサポートする設定は、以下の要件を満たす必要があります。

mod_cluster を使用して Undertow をロードバランサーとして設定する方法の詳細は、JBoss EAP設定ガイドの mod_cluster を使用して Undertow をロードバランサーとして設定 を参照してください。

ロードバランサーを介して通信するメッセージングクライアントの設定

ロードバランサーに接続するクライアントでは、クラスタートポロジーを使用してロードバランサーに接続するのではなく、初期接続を再利用するように設定する必要があります。

最初の接続を再利用すると、クライアントが同じサーバーに接続します。クラスタートポロジーを使用すると、メッセージが別のサーバーに転送され、トランザクション処理が中断される可能性があります。

ロードバランサーへの接続に使用される接続ファクトリーまたはプールされた接続ファクトリーは、use-topology-for-load-balancing 属性を false に設定する必要があります。以下の例では、CLI でこの設定を定義する方法を示しています。

/subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name=use-topology-for-load-balancing, value=false)

バックエンドワーカーの設定

バックエンドメッセージングワーカーは、ロードバランサーの内側で JNDI ルックアップを行う予定がある場合のみ設定する必要があります。

JBoss EAP には、バインディングデータとメッセージを格納するための次の 2 つの永続性オプションが備わっています。

JBoss EAP メッセージングには、メッセージング向けに最適化された高パフォーマンスのファイルベースのジャーナルが備わっています。

JBoss EAP メッセージングジャーナルのファイルには設定可能なファイルサイズがあります。また、このジャーナルは、追加のみ可能です。このように単一の書き込み操作を有効にすることでパフォーマンスが向上します。これは、ディスク上の 1 組のファイルで設定されます。このファイルは、最初に固定サイズで事前作成され、パディングが書き込まれます。メッセージの追加、削除、更新などのサーバーオペレーションが実行されると、ジャーナルファイルが満杯になるまで、オペレーションの記録が追加されます。満杯になると、次のジャーナルファイルが使用されます。

すべてのデータが削除された場合、高度なガベージコレクションアルゴリズムにより、ジャーナルファイルを回収して再利用できるかどうかが決定されます。圧縮アルゴリズムにより、ジャーナルファイルから不要な領域が削除され、データが圧縮されます。

またジャーナルは、ローカルトランザクションと XA トランザクションの両方に完全に対応しています。

/subsystem=messaging-activemq/server=default/path=bindings-directory:read-resource

{
    "outcome" => "success",
    "result" => {
        "path" => "activemq/bindings",
        "relative-to" => "jboss.server.data.dir"
    }
}

/subsystem=messaging-activemq/server=default/path=bindings-directory:write-attribute(name=path,value=PATH_LOCATION)

/subsystem=messaging-activemq/server=default/path=bindings-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)

/subsystem=messaging-activemq/server=default:write-attribute(name=create-bindings-dir,value=TRUE/FALSE)

/subsystem=messaging-activemq/server=default/path=journal-directory:read-resource
{
    "outcome" => "success",
    "result" => {
        "path" => "activemq/journal",
        "relative-to" => "jboss.server.data.dir"
    }
}

/subsystem=messaging-activemq/server=default/path=journal-directory:write-attribute(name=path,value=PATH_LOCATION)

/subsystem=messaging-activemq/server=default/path=journal-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)

/subsystem=messaging-activemq/server=default:write-attribute(name=create-journal-dir,value=TRUE/FALSE)

/subsystem=messaging-activemq/server=default:read-attribute(name=ATTRIBUTE_NAME)

/subsystem=messaging-activemq/server=default:write-attribute(name=ATTRIBUTE_NAME,value=NEW_VALUE)

デフォルトのファイルベースのジャーナルを使用するのではなく、JDBC を使用してメッセージを永続化し、データをデータベースにバインドするように、JBoss EAP 7 メッセージングを設定できます。この設定を行うには、まず datasources サブシステムの datasource 要素を設定し、次に messaging-activemq サブシステムの server 要素で journal-datasource 属性を定義して、データソースを使用する必要があります。journal-datasource 属性が存在すると、ファイルベースのジャーナルではなくジャーナルエントリーをデータベースに永続化することを、メッセージングサブシステムに通知します。messaging -activemq サブシステムの server リソースの journal-database 属性は、データベースとの通信に使用される SQL ダイアレクトを定義します。これはデータソースメタデータを使用して自動的に設定されます。

メッセージをファイルベースのジャーナルに永続化すると、大きいメッセージのサイズはディスクのサイズによってのみ制限されます。ただし、メッセージをデータベースに永続化すると、大きなメッセージのサイズは、そのデータベースの BLOB データ型の最大サイズに制限されます。

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-page-store-table,value="\"PAGE_DATA\"")

<server name="default">
  <journal datasource="MessagingOracle12cDS" journal-page-store-table="&quot;PAGED_DATA&quot;"/>
  ...
</server>

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-page-store-table,value="${env.NODE_ID}_page_store")

data-source add --name=messaging-journal --jndi-name=java:jboss/datasources/messaging-journal --driver-name=oracle12c  --connection-url=${env.DB_CONNECTION_URL}

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-jdbc-network-timeout,value=10000)

以下の管理 CLI コマンドを使用して、メッセージングジャーナルの準備済みトランザクションを管理できます。

メッセージングシステムに、ゼロ永続化が必要になる場合があります。ゼロ永続化とは、バインドデータ、メッセージデータ、大きなメッセージデータ、重複した ID キャッシュ、またはページングデータの永続化ができないことです。

messaging-activemq サブシステムがゼロ永続化を実行するように設定するには、persistence-enabled パラメーターを false に設定します。

/subsystem=messaging-activemq/server=default:write-attribute(name=persistence-enabled,value=false)

ジャーナルデータのインポートとエクスポートの詳細は、JBoss EAP 7移行ガイド を参照してください。

JBoss EAP メッセージングは多数のメッセージキューをサポートし、各キューには何百万というメッセージが含まれています。JBoss EAP メッセージングサーバーは制限されたメモリーで実行されるため、一度にすべてのメッセージキューをメモリーに格納することは困難です。

ページングは、JBoss EAP メッセージングサーバーで使用されるメカニズムで、限られたメモリーに大きなメッセージキューを収容するために、必要に応じてメッセージを透過的にメモリー内外にページングします。

JBoss EAP メッセージングでは、特定のアドレスのメモリー内のメッセージサイズが最大設定メッセージサイズを超えると、メッセージのディスクへのページングが開始されます。

複数のファイルにメッセージを格納するファイルシステムの各アドレスには、個別のフォルダーがあります。メッセージを格納するこれらのファイルは、ページファイルと呼ばれます。各ファイルには page-size-bytes 属性で設定された最大設定メッセージサイズに達するまでメッセージが収容されます。

システムは必要に応じてページファイルを移動して、ページのメッセージがすべてクライアントに受信されるとすぐにページファイルを削除します。

以下の管理 CLI コマンドを使用すると、ページングディレクトリーの設定を読み込むことができます。この例では、出力にはデフォルト設定が表示されます。

/subsystem=messaging-activemq/server=default/path=paging-directory:read-resource
{
    "outcome" => "success",
    "result" => {
        "path" => "activemq/paging",
        "relative-to" => "jboss.server.data.dir"
    }
}

paging-directory 設定要素は、ページファイルを格納するファイルシステムの場所を指定します。JBoss EAP は、このページングディレクトリーに各ページングアドレスのフォルダーを作成します。また、ページファイルはこれらのフォルダーに格納されます。デフォルトでは、このパスは activemq/paging/ です。以下の管理 CLI コマンドを使用すると、パスの場所を変更できます。

/subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=path,value=PATH_LOCATION)

また、上記の出力例の relative-to 属性にも注意してください。relative-to が指定されている場合、path 属性の値は relative-to 属性によって指定されるファイルパスの相対値となります。デフォルトでは、この値は JBoss EAP の jboss.server.data.dir プロパティーです。スタンドアロンサーバーの場合、jboss.server.data.dir は EAP_HOME/standalone/data/ にあります。管理対象ドメインの場合、各サーバーは EAP_HOME/domain /servers/ の下に独自の serverX/data/activemq/ ディレクトリーを持ちます。以下の管理 CLI コマンドを使用すると relative-to の値を変更できます。

/subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)

アドレスに配信されるメッセージが設定サイズを超える場合、そのアドレスはページングモードになります。

page モードであっても、メモリー不足によるエラーが原因でサーバーがクラッシュする可能性があります。JBoss EAP メッセージングは、ディスク上の各ページファイルへの参照を維持します。ページファイルが非常に多くなると、JBoss EAP メッセージングでメモリーを使い切る可能性があります。このリスクを最小限に抑えるには、page-size-bytes 属性を適切な値に設定することが重要になります。JBoss EAP メッセージングサーバーのメモリーを max-size-bytes の宛先の数倍の 2 倍以上になるよう設定する必要があります。この設定を行わなければ、メモリー不足によるエラーが発生する可能性があります。

以下の管理 CLI コマンドを使用すると、アドレスの現在の最大サイズ (バイト単位) (max-size-bytes) を読み取ることができます。

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:read-attribute(name=max-size-bytes)

以下の管理 CLI コマンドを使用すると、アドレスの最大サイズ (バイト単位) (max-size-bytes) を設定できます。

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:write-attribute(name=max-size-bytes,value=MAX_SIZE)

アドレス設定で別のページング関連属性の値を読み取りまたは書き込みする場合は、同様の構文を使用してください。以下の表は、各属性の説明とデフォルト値を一覧表示しています。

以下の表には、アドレス設定のパラメーターをまとめています。

複数のキューを持つアドレス

複数のキューがバインドされているアドレスへメッセージが転送されると、メッセージのコピーはメモリー内に 1 つだけ存在します。各キューではこのメッセージの元のコピーを参照するだけなので、元のメッセージを参照するすべてのキューがメッセージを配信すると、はじめてメモリーが解放されます。

標準的な方法で大きなメッセージを送信する場合、メッセージを送信するのに必要なヒープサイズはメッセージのサイズの 4 倍以上になる可能性があります (つまり 1 GB のメッセージでは 4 GB のヒープメモリーが必要になる可能性があります)。このため、JBoss EAP メッセージングでは、java.io.InputStream と java.io.OutputStream クラスを使用してメッセージのボディーの設定をサポートしていますが、これに必要なメモリーはそれほど多くありません。入力ストリームがメッセージと出力ストリームの送信にそのまま使用され、メッセージの受信に使用されます。

メッセージの受信時に、出力ストリームを処理する方法は 2 つあります。

メッセージの送信に java.io.InputStream を実装し、メッセージの受信に java.io.OutputStream を実装している限り、ストリームの種類に関係なく (ファイル、JDBC Blob、または SocketInputStream など) 使用できます。

コア API を使用した大きなメッセージのストリーミング

以下の表に、オブジェクトプロパティーを使用して JMS で利用可能な ClientMessage クラスで使用できるメソッドを示します。

以下のコード例では、コアメッセージを受信する際に出力ストリームを設定します。

ClientMessage firstMessage = consumer.receive(...);

// Block until the stream is transferred
firstMessage.saveOutputStream(firstOutputStream);

ClientMessage secondMessage = consumer.receive(...);

// Do not wait for the transfer to finish
secondMessage.setOutputStream(secondOutputStream);

以下のコード例では、コアメッセージを送信する際に入力ストリームを設定します。

ClientMessage clientMessage = session.createMessage();
clientMessage.setInputStream(dataInputStream);

JMS での大きなメッセージのストリーミング

JMS を使用する場合、JBoss EAP メッセージングはオブジェクトプロパティーを設定して、コア API ストリーミングメソッドをマッピングします。Message.setObjectProperty(String name, Object value) メソッドを使用して入力ストリームと出力ストリームを設定します。

InputStream は、送信メッセージで JMS_AMQ_InputStream プロパティーを使用して設定されます。

BytesMessage bytesMessage = session.createBytesMessage();
FileInputStream fileInputStream = new FileInputStream(fileInput);
BufferedInputStream bufferedInput = new BufferedInputStream(fileInputStream);
bytesMessage.setObjectProperty("JMS_AMQ_InputStream", bufferedInput);
someProducer.send(bytesMessage);

OutputStream は、ブロックの方法で受信されたメッセージの JMS_AMQ_SaveStream プロパティーを使用して設定されます。

BytesMessage messageReceived = (BytesMessage) messageConsumer.receive(120000);
File outputFile = new File("huge_message_received.dat");
FileOutputStream fileOutputStream = new FileOutputStream(outputFile);
BufferedOutputStream bufferedOutput = new BufferedOutputStream(fileOutputStream);

// This will block until the entire content is saved on disk
messageReceived.setObjectProperty("JMS_AMQ_SaveStream", bufferedOutput);

JMS_AMQ_OutputStream プロパティーを使用すると、OutputStream をブロック以外の方法で設定することもできます。

// This does not wait for the stream to finish. You must keep the consumer active.
messageReceived.setObjectProperty("JMS_AMQ_OutputStream", bufferedOutput);

期限切れアドレスを設定して、有効期限切れのメッセージを送信する場所を指定できます。メッセージの有効期限が切れて期限切れアドレスが指定されていない場合、メッセージはキューから削除されドロップされます。

管理 CLI を使用して、address-setting の expiry-address を設定できます。以下の例では、jms.queue.exampleQueue キューの有効期限切れのメッセージが jms.queue.expiryQueue 期限切れアドレスに送信されます。

/subsystem=messaging-activemq/server=default/address-setting=jms.queue.exampleQueue:write-attribute(name=expiry-address,value=jms.queue.expiryQueue)

リーパースレッドは定期的にキューを検査して、メッセージの有効期限が切れているかどうかを確認します。管理 CLI を使用して、リーパースレッドのスキャン期間とスレッド優先度を設定できます。

期限切れリーパースレッドのスキャン期間を設定します。スキャン期間は、有効期限切れのメッセージを検出するためにキューをスキャンする頻度 (ミリ秒単位) です。デフォルトは 30000 です。このパラメーターを -1 に設定するとリーパースレッドを無効にできます。

/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-scan-period,value=30000)

期限切れリーパースレッドのスレッド優先度を設定します。設定可能な値は 0 から 9 までで、9 の優先度が最も高くなります。デフォルトは 3 です。

/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-thread-priority,value=3)

JBoss EAP メッセージングには、コンシューマーのために事前にフェッチするデータ量を定義する設定とコンシューマーがメッセージを消費できる速度を制御する設定が含まれています。

ウィンドウベースのフロー制御

JBoss EAP メッセージングでは、メッセージを各コンシューマーのバッファーに事前フェッチします。バッファーサイズは connection-factory の consumer-window-size 属性で決定されます。次の設定例は、consumer-window-size 属性を明示的に設定した connection-factory を示しています。

<connection-factory name="MyConnFactory" ... consumer-window-size="1048576" />

管理 CLI を使用して、特定の connection-factory の consumer-window-size 属性の値を読み書きします。以下の例は、InVmConnectionFactory 接続ファクトリーを使用して実行する方法を示しています。これはサーバーと同じ仮想マシンに存在するコンシューマー (たとえば、ローカルの MessageDrivenBean) のデフォルトです。

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:read-attribute(name=consumer-window-size)
{
    "outcome" => "success",
    "result" => 1048576
}

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:write-attribute(name=consumer-window-size,value=1048576)
{"outcome" => "success"}

consumer-window-size の値は整数である必要があります。以下の表に記載されているように、特別な意味を持つ値もあります。

コア API を使用している場合、setConsumerWindowSize() メソッドを使用して ServerLocator からコンシューマーウインドウサイズを設定できます。

JMS を使用している場合、クライアントはインスタンス化された ConnectionFactory の setConsumerWindowSize() メソッドを使用してコンシューマーウインドウのサイズを指定できます。

レート制限フロー制御

JBoss EAP メッセージングは、メッセージを消費するレートを 1 秒単位で制限できます。これはスロットルと呼ばれるフロー制御メソッドです。適切な connection-factory の consumer-max-rate 属性を使用して、指定した速度よりも早くコンシューマーがメッセージを消費しないようにします。

<connection-factory name="MyConnFactory" ... consumer-max-rate="10" />

デフォルト値は -1 で、レート制限フロー制御を無効にします。

consumer-max-rate 属性の読み取りおよび書き込みには、管理 CLI を使用することが推奨されます。以下の例は、InVmConnectionFactory 接続ファクトリーを使用して実行する方法を示しています。これはサーバーと同じ仮想マシンに存在するコンシューマー (たとえば、ローカルの MessageDrivenBean) のデフォルトです。

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:read-attribute(name=consumer-max-rate)
{
    "outcome" => "success",
    "result" => -1
}

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:write-attribute(name=consumer-max-rate,value=100)
{"outcome" => "success"}

JMS を使用している場合、インスタンス化された ConnectionFactory の setConsumerMaxRate(int consumerMaxRate) メソッドを使用して最大レートサイズを設定できます。

コア API を使用している場合、速度は ServerLocator.setConsumerMaxRate(int consumerMaxRate) メソッドで設定できます。

JBoss EAP メッセージングは、サーバーの処理能力を超えるメッセージを受信しないように、クライアントから送信されるデータの量を制限することもできます。

ウィンドウベースのフロー制御

JBoss EAP メッセージングは、クレジットの交換を使用して、メッセージプロデューサーを制御します。プロデューサーは、これを行うのに十分なクレジットがある限り、メッセージをアドレスに送信することができます。メッセージを送信するのに必要なクレジットの量は、メッセージのサイズで決定されます。プロデューサーのクレジットが欠乏している場合、プロデューサーはサーバーからさらに多くのクレジットを要求します。サーバーの設定の中では、プロデューサーが一度に要求できるクレジットの量は producer-window-size と呼ばれ、次の connection-factory 要素の属性です。

<connection-factory name="MyConnFactory" ... producer-window-size="1048576" />

ウィンドウサイズで一度に送信できるバイト量が決定されるため、リモート接続によってサーバーに過重な負荷がかかるのを防ぎます。

管理 CLI を使用して、特定の接続ファクトリーの producer-window-size 属性を読み書きします。以下の例では RemoteConnectionFactory を使用しています。これはデフォルト設定に含まれており、リモートクライアントでの使用を目的としています。

subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-attribute(name=producer-window-size)
{
    "outcome" => "success",
    "result" => 65536
}

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=producer-window-size,value=65536)
{"outcome" => "success"}

JMS を使用している場合、クライアントは ConnectionFactory の setProducerWindowSize(int producerWindowSize) メソッドを呼び出してウィンドウサイズを直接設定できます。

コア API を使用している場合、ServerLocator の setProducerWindowSize(int producerWindowSize) メソッドを使用してウィンドウサイズを設定できます。

プロデューサーウインドウベースのフロー制御のブロック

通常、メッセージングサーバーはリクエストされたのと同じ数のクレジットを提供します。ただし、サーバーから送信されるクレジットの数を制限することは可能で、これによりプロデューサーが一度に処理できる数を超えるメッセージを送信してメモリー不足に陥るのを防止できます。

たとえば、myqueue という JMS キューがあり、最大メモリーサイズを 10MB に設定すると、サーバーによってキュー内のメッセージ数が制限され、サイズが 10MB を超えることはなくなります。アドレスが満杯になると、十分な領域がアドレス上で解放されるまで、プロデューサーがクライアント側でブロックされます。

address-setting 設定要素には、プロデューサーフロー制御のブロックを管理する設定が含まれます。address-setting は、そのアドレスに登録されているすべてのキューに一連の設定を適用するために使用されます。実施方法の詳細は、アドレス設定の設定 を参照してください。

プロデューサーフロー制御をブロックするのに必要な address-setting にはそれぞれ max-size-bytes 属性の値を含める必要があります。そのアドレスにバインドされるすべてのキューの合計メモリーが max-size-bytes を超えることはできません。JMS トピックの場合、トピックのすべてのサブスクリプションの合計メモリーが max-size-bytes を超えることができないことを意味します。

また、address-full-policy 属性を BLOCK に設定することも必要です。これによってプロデューサーは max-size-bytes に達するとブロックする必要があることを認識します。以下の例は、両方の属性セットを持つ address-setting です。

<address-setting ...
      name="myqueue"
      address-full-policy="BLOCK"
      max-size-bytes="100000" />

上記の例では、JMS キューの myqueue の最大サイズを 100000 バイトに設定します。プロデューサーは、最大サイズに達した時点で、そのアドレスへの送信がブロックされます。

以下の例のように、管理 CLI を使用してこれらの属性を設定します。

/subsystem=messaging-activemq/server=default/address-setting=myqueue:write-attribute(name=max-size-bytes,value=100000)
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default/address-setting=myqueue:write-attribute(name=address-full-policy,value=BLOCK)
{"outcome" => "success"}

レート制限フロー制御

JBoss EAP メッセージングでは、以下の例のように、プロデューサーが使用する connection-factory の producer-max-rate を指定すると、プロデューサーが 1 秒あたりに送信できるメッセージの数を制限します。

<connection-factory name="MyConnFactory" producer-max-rate="1000" />

デフォルト値は -1 で、レート制限フロー制御を無効にします。

管理 CLI を使用して producer-max-rate の値を読み書きします。以下の例では RemoteConnectionFactory を使用しています。これはデフォルト設定に含まれており、リモートクライアントでの使用を目的としています。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-attribute(name=producer-max-rate)
{
    "outcome" => "success",
    "result" => -1
}

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=producer-max-rate,value=100)
{"outcome" => "success"}

コア API を使用する場合は、ServerLocator.setProducerMaxRate(int producerMaxRate) メソッドを使用してレートを設定します。

JNDI を使用して接続ファクトリーのインスタンス化と検索を行う場合、インスタンス化された接続ファクトリーの setProducerMaxRate(int producerMaxRate) メソッドを使用して最大レートをクライアントに設定できます。

以下のように管理 CLI を使用して pre-acknowledge 属性を true に設定すると、接続ファクトリーを事前承認モードを使用するように設定できます。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=pre-acknowledge,value=true)

事前承認モードは、jndi.properties ファイルなどでクライアントの JNDI コンテキスト環境で設定することが可能です。

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connection.ConnectionFactory=tcp://localhost:8080?preAcknowledge=true

または、JMS API を使用して事前確認モードを使用するには、ActiveMQSession.PRE_ACKNOWLEDGE 定数で JMS セッションを作成します。

// messages will be acknowledge on the server *before* being delivered to the client
Session session = connection.createSession(false, ActiveMQJMSConstants.PRE_ACKNOWLEDGE);

インターセプターでは次のインターセプターインターフェイスを実装する必要があります。

package org.apache.artemis.activemq.api.core.interceptor;

public interface Interceptor
{
   boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException;
}

返されるブール値は重要です。

インターセプタークラスをモジュールとして JBoss EAP に追加する必要があります。詳細は、JBoss EAP設定ガイドの カスタムモジュールの作成 を参照してください。

JBoss EAP にカスタムモジュールとしてモジュールを追加した後、着信インターセプターと発信インターセプターは共に、管理 CLI を使用してメッセージングサブシステムの設定に追加されます。

以下の管理 CLI コマンドの例にしたがって、各インターセプターを追加する必要があります。この例では、各インターセプターをカスタムモジュールとして JBoss EAP に追加済みであると仮定しています。

/subsystem=messaging-activemq/server=default:list-add(name=incoming-interceptors, value={name => "foo.bar.MyIncomingInterceptor", module=>"foo.bar.interceptors"})

発信インターセプターを追加する場合は、以下の例に示すものと同様の構文に従います。

/subsystem=messaging-activemq/server=default:list-add(name=outgoing-interceptors, value={name => "foo.bar.MyOutgoingInterceptor", module=>"foo.bar.interceptors"})

_AMQ_GROUP_ID プロパティーは、クライアント側でコア API を使用してメッセージグループを特定するために使用されます。ランダムな一意のメッセージグループ識別子を選択するために、SessionFactory で auto-group プロパティーを true に設定することもできます。

JMSXGroupID プロパティーは、Java Messaging Service (JMS) クライアントのメッセージグループを特定するために使用されます。別のメッセージを持つメッセージグループを 1 つのコンシューマーに送信する場合は、異なるメッセージに対して同じ JMSXGroupID を設定することができます。

Message message = ...
message.setStringProperty("JMSXGroupID", "Group-0");
producer.send(message);

message = ...
message.setStringProperty("JMSXGroupID", "Group-0");
producer.send(message);

別の方法としては、クライアントによって使用される connection-factory の auto-group または group-id のいずれかの属性を使用することができます。

auto-group を true に設定すると、その connection-factory を介して送信されたすべてのメッセージにランダムな一意のメッセージグループ識別子を使用するようになります。管理 CLI を使用して auto-group 属性を設定できます。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=auto-group,value=true)

その接続ファクトリーを介して送信されたすべてのメッセージに対して、group-id 属性によって JMSXGroupID プロパティーが指定された値に設定されます。接続ファクトリーに特定の group-id を設定するには、管理 CLI を使用します。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=group-id,value="Group-0")

以下の例は、設定で見られる可能性がある特別な迂回を示しています。

<divert
  name="prices-divert"
  address="jms.topic.priceUpdates"
  forwarding-address="jms.queue.priceForwarding"
  filter="office='New York'"
  transformer-class-name="org.apache.activemq.artemis.jms.example.AddForwardingTimeTransformer"
  exclusive="true"/>

この例では、prices-divert と呼ばれる迂回が、アドレス jms.topic.priceUpdates に送信されたメッセージを迂回するように設定されています。これは priceUpdates という JMS トピックに送信されたすべてのメッセージを、priceForwarding というローカル JMS キューに対応する別のローカルアドレス jms.queue.priceForwarding にマッピングしています。

また、値が New York のメッセージプロパティー office を持つメッセージのみを迂回するようにメッセージフィルター文字列を指定します。その他のメッセージはすべて、今までどおり通常のアドレスへルーティングされます。フィルター文字列はオプションです。指定されていない場合は、すべてのメッセージが一致したとみなされます。

トランスフォーマークラスが指定されていることに注意してください。この例では、トランスフォーマーは迂回が発生した時間を記録するヘッダーを追加するだけです。

この例では、実際にメッセージをローカルストアと転送キューに迂回しています。これは、メッセージを別のサーバーのアドレスに転送するブリッジで設定されています。詳細は、コアブリッジの設定 を参照してください。

以下は、特別でない迂回の例です。特別でない迂回は、オプションのフィルターとトランスフォーマーを使用して特別な迂回と同じ方法で設定できます。

<divert
  name="order-divert"
  address="jms.queue.orders"
  forwarding-address="jms.topic.spytopic"
  exclusive="false"/>

上記の迂回は、アドレス jms.queue.orders に送信されたすべてのメッセージのコピーを取ります。そして orders という JMS キューにマッピングされ、SpyTopic という JMS トピックに対応する jms.topic.SpyTopic というローカルアドレスに送信されます。

迂回の作成

管理 CLI を使用して、必要な迂回のタイプを作成します。

/subsystem=messaging-activemq/server=default/divert=my-divert:add(divert-address=news.in,forwarding-address=news.forward)

デフォルトでは、特別でない迂回が作成されます。特別な迂回を作成するには、exclusive 属性を使用します。

/subsystem=messaging-activemq/server=default/divert=my-exclusive-divert:add(divert-address=news.in,forwarding-address=news.forward,exclusive=true)

以下の表は、迂回の属性とその説明を示しています。この情報は、管理 CLI で以下のコマンドを使用して表示できます。

/subsystem=messaging-activemq/server=default/divert=*:read-resource-description()

サーバースケジュールスレッドプールは、定期的に実行する必要がある、または遅れて実行する必要があるサーバーサイドの多くのアクティビティーに使用されます。内部的には、java.util.concurrent.ScheduledThreadPoolExecutor インスタンスにマッピングします。

このプールによって使用されるスレッドの最大数は、scheduled-thread-pool-max-size パラメーターを使用して設定します。デフォルト値は 5 スレッドです。通常、このプールには少ない数のスレッドで十分です。デフォルトの JBoss EAP メッセージングサーバーのこの値を変更するには、以下の管理 CLI コマンドを使用します。

/subsystem=messaging-activemq/server=default:write-attribute(name=scheduled-thread-pool-max-size,value=10)

汎用スレッドプールは、サーバー側でほとんどの非同期操作に使用されます。内部的には、java.util.concurrent.ThreadPoolExecutor インスタンスにマッピングします。

このプールによって使用されるスレッドの最大数は、thread-pool-max-size 属性を使用して設定します。

thread-pool-max-size が -1 に設定された場合、スレッドプールには上限がなく、要求を満たすのに十分なスレッドが利用できない場合は、新しいスレッドが要求に応じて作成されます。その後アクティビティーがおさまると、スレッドはタイムアウトになり、閉じられます。

thread-pool-max-size がゼロより大きい正の整数に設定されている場合、スレッドプールはバインドされます。要求を受け取り、プールに利用可能な空きスレッドがない場合、要求はスレッドが利用可能になるまでブロックされます。バインドされたスレッドプールは、上限が非常に低く設定された場合にデッドロックの状況になることがあるため、注意して使用することが推奨されます。

thread-pool-max-size のデフォルト値は 30 です。デフォルトの JBoss EAP メッセージングサーバーに新しい値を設定するには、以下の管理 CLI コマンドを使用します。

/subsystem=messaging-activemq/server=default:write-attribute(name=thread-pool-max-size,value=40)

バインドされない (キャッシュ) スレッドプールとバインドされる (固定) スレッドプールの詳細については、ThreadPoolExecutor の Javadoc を参照してください。

スレッドの使用状況をチェックして、スレッドプールのサイズを適切に設定していることを確認します。

スレッドの使用状況をチェックするには、以下の CLI コマンドを実行します。

/subsystem=messaging-activemq:read-resource(include-runtime)

システムは以下のような結果を返します。

{
    "outcome" => "success",
    "result" => {
        "global-client-scheduled-thread-pool-active-count" => 0,
        "global-client-scheduled-thread-pool-completed-task-count" => 0L,
        "global-client-scheduled-thread-pool-current-thread-count" => 0,
        "global-client-scheduled-thread-pool-keepalive-time" => 10000000L,
        "global-client-scheduled-thread-pool-largest-thread-count" => 0,
        "global-client-scheduled-thread-pool-max-size" => undefined,
        "global-client-scheduled-thread-pool-task-count" => 0L,
        "global-client-thread-pool-active-count" => 0,
        "global-client-thread-pool-completed-task-count" => 2L,
        "global-client-thread-pool-current-thread-count" => 2,
        "global-client-thread-pool-keepalive-time" => 60000000000L,
        "global-client-thread-pool-largest-thread-count" => 2,
        "global-client-thread-pool-max-size" => undefined,
        "global-client-thread-pool-task-count" => 2L,
        "connection-factory" => undefined,
        "connector" => undefined,
        "discovery-group" => undefined,
        "external-jms-queue" => undefined,
        "external-jms-topic" => undefined,
        "http-connector" => undefined,
        "in-vm-connector" => undefined,
        "jms-bridge" => undefined,
        "pooled-connection-factory" => undefined,
        "remote-connector" => undefined,
        "server" => {"default" => undefined}
    }
}

キュー内の期限が切れたメッセージをスキャンするためにサーバー側でも単一のスレッドが使用されます。このスレッドは、独自の設定可能な優先順位で実行する必要があるため、このためにスレッドプールのいずれかを使用することはできません。

非同期 IO には、ネイティブレイヤーからイベントを送受信するためのスレッドプールがあります。これは、接頭辞が ArtemisMQ-AIO-poller-pool のスレッドダンプ上にあります。JBoss EAP メッセージングは、ジャーナル上で開かれたファイルごとに 1 つのスレッドを使用します (通常は 1 つあります)。

また、libaio への書き込みを呼び出すために使用される単一のスレッドもあります。これは、libaio 上で、パフォーマンスの問題を引き起こすコンテキスト切り替えを回避するために行われます。このスレッドは、接頭辞が ArtemisMQ-AIO-writer-pool のスレッドダンプ上で見つかります。

JBoss EAP には、クライアント接続の作成に使用されるクライアントスレッドプールが含まれています。このプールは、本章で前述した静的プールとは別のもので、クライアントのように動作するときに JBoss EAP によって使用されます。たとえば、クライアントスレッドプールクライアントは、同じクラスター内の他のノードとのクラスター接続として作成されます。または Artemis リソースアダプターが JBoss EAP のリモートインスタンス内で統合されたリモート Apache ActiveMQ Artemis メッセージングサーバーに接続するときに作成されます。スケジュールクライアントスレッドにもプールがあります。

管理 CLI を使用したクライアントスレッドプールサイズの設定

管理 CLI を使用して、クライアントスレッドプールとクライアントスケジュールスレッドプールの両方のサイズを設定します。管理 CLI を使用して設定したプールサイズは、システムプロパティーを使用して設定するサイジングよりも優先されます。

以下のコマンドは、クライアントスレッドプールを設定します。

/subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=POOL_SIZE)

この属性に定義されるデフォルト値はありません。属性が定義されていない場合、プールの最大サイズは、CPU コアプロセッサー数の 8 倍になるように決定されます。

現在の設定を確認するには、以下のコマンドを使用します。

/subsystem=messaging-activemq:read-attribute(name=global-client-thread-pool-max-size)

クライアントスケジュールスレッドプールのサイズは、以下のコマンドを使用して設定します。

/subsystem=messaging-activemq:write-attribute(name=global-client-scheduled-thread-pool-max-size,value=POOL_SIZE)

以下は、クライアントスケジュールスレッドプールの現在のプールのサイズを表示します。デフォルト値は 5 です。

/subsystem=messaging-activemq:read-attribute(name=global-client-scheduled-thread-pool-max-size)

システムプロパティーを使用したクライアントスレッドプールサイズの設定

以下のシステムプロパティーは、クライアントのグローバルおよびグローバルスケジュールスレッドプールのサイズをそれぞれ設定するために使用できます。

以下の例のように、システムプロパティーは XML 設定で参照できます。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <global-client thread-pool-max-size="${activemq.artemis.client.global.thread.pool.max.size}"
    scheduled-thread-pool-max-size="${activemq.artemis.client.global.scheduled.thread.pool.core.size}" />
  <server ...>
  </server>
  ...
</subsystem>

独自のスレッドプールを使用するようにクライアントを設定する

クライアントは、各 ClientSessionFactory インスタンスが JBoss EAP によって提供されるプールを使用せず、独自のクライアントスレッドプールを使用するように設定できます。この ClientSessionFactory から作成されるセッションはどれも、新規作成されるプールを使用します。

ClientSessionFactory インスタンスが独自のプールを使用するように設定するには、ファクトリーの作成後すぐに適切なセッターメソッドを呼び出します。例を以下に示します。

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(transportConfiguration);
locator.setUseGlobalPools(true);
locator.setThreadPoolMaxSize(-1);
locator.setScheduledThreadPoolMaxSize(10);
ClientSessionFactory myFactory = locator.createSessionFactory();

JMS API を使用している場合は、ClientSessionFactory に同じパラメーターを設定できます。例を以下に示します。

ActiveMQConnectionFactory myConnectionFactory = ActiveMQJMSClient.createConnectionFactory(url, "ConnectionFactoryName");
myConnectionFactory.setUseGlobalPools(false);
myConnectionFactory.setScheduledThreadPoolMaxSize(10);
myConnectionFactory.setThreadPoolMaxSize(-1);

JNDI を使用して ActiveMQConnectionFactory インスタンスをインスタンス化する場合は、JBoss EAP のスタンドアロンインスタンスの以下の例にあるように管理 CLI を使用してこれらのパラメーターを設定することもできます。

/subsystem=messaging-activemq/server=default/connection-factory=myConnectionFactory:write-attribute(name=use-global-pools,value=false)

/subsystem=messaging-activemq/server=default/connection-factory=myConnectionFactory:write-attribute(name=scheduled-thread-pool-max-size,value=10)

/subsystem=messaging-activemq/server=default/connection-factory=myConnectionFactory:write-attribute(name=thread-pool-max-size,value=1)

上記の各コマンドを実行すると、インスタンスのリロードが必要であることが管理 CLI により通知されることに注意してください。

送信されたメッセージに対して重複メッセージ検出を有効にするには、org.apache.activemq.artemis.api.core.Message.HDR_DUPLICATE_DETECTION_ID プロパティーの値を設定する必要があります。これにより、_AMQ_DUPL_ID に解決され、一意の値になります。ターゲットサーバーがメッセージを受信すると、_AMQ_DUPL_ID プロパティーが設定されている場合は、メモリーキャッシュをチェックして、そのヘッダーの値が含まれるメッセージをすでに受信したかどうかを確認します。すでに受信した場合、このメッセージは無視されます。詳細は、重複 ID キャッシュの設定 を参照してください。

コア API を使用している場合は、_AMQ_DUPL_ID プロパティーの値を byte[] または SimpleString 型にすることができます。JMS を使用している場合は、String である必要があります。

以下の例は、コア API のプロパティーを設定する方法を示しています。

SimpleString myUniqueID = "This is my unique id";   // Can use a UUID for this

ClientMessage message = session.createMessage(true);
message.setStringProperty(HDR_DUPLICATE_DETECTION_ID, myUniqueID);

以下の例は、JMS クライアントのプロパティーを設定する方法を示しています。

String myUniqueID = "This is my unique id";   // Can use a UUID for this

Message jmsMessage = session.createMessage();
message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID);

サーバーは、各アドレスに送信される _AMQ_DUPL_ID プロパティーの受信値のキャッシュを維持します。各アドレスは独自のアドレスキャッシュを維持します。

キャッシュのサイズは固定です。キャッシュの最大サイズは id-cache-size 属性を使用して設定します。このパラメーターのデフォルト値は 20000 要素です。キャッシュの最大サイズが n 要素の場合は、(n + 1) 番目の ID が保存され、キャッシュ内の要素 0 が上書きされます。この値は、以下の管理 CLI コマンドを使用して設定します。

/subsystem=messaging-activemq/server=default:write-attribute(name=id-cache-size,value=SIZE)

キャッシュは、ディスクに永続的に残るように設定することもできます。これを設定するには、以下の管理 CLI コマンドを使用して persist-id-cache 属性を設定します。

/subsystem=messaging-activemq/server=default:write-attribute(name=persist-id-cache,value=true)

この値を true に設定すると、各 ID は受信時に永続ストレージに永続的に残ります。このパラメーターのデフォルト値は true です。

JBoss EAP の quality-of-service は、メッセージが消費され、確認応答される方法を決定する設定可能な属性です。quality-of-service の有効な値とその説明を以下に示します。JMS ブリッジ属性の完全なリストは、付録の表 を参照してください。

ONCE_AND_ONLY_ONCE ではなく DUPLICATES_OK モードを使用し、宛先で重複を確認して破棄することにより、1 回限りのセマンティクスを提供できる可能性があります。詳細は、重複メッセージ検出の設定 を参照してください。ただし、キャッシュは一定期間のみ有効になります。そのため、このアプローチは ONCE_AND_ONLY_ONCE を使用するほどは完璧ではありませんが、特定のアプリケーションのニーズによっては適切な選択肢となる可能性があります。

ターゲットサーバーまたはソースサーバーは、ある時点で利用できなくなることがあります。これが発生すると、ブリッジは max-retries の値と同じ回数、再接続を試みます。試行までの待機時間は、failure-retry-interval で設定します。

コアブリッジは、メッセージをターゲットに転送する前に、一意の重複 ID 値 (メッセージ内にまだない場合) を自動的に追加するように設定できます。重複メッセージ検出にコアブリッジを設定するには、use-duplicate-detection 属性を true (デフォルト値) に設定します。

/subsystem=messaging-activemq/server=default/bridge=my-core-bridge:write-attribute(name=use-duplicate-detection,value=true)

サーバー検出は、サーバーが以下の対象に接続詳細を伝播できるメカニズムです。

この情報、またはクラスタートポロジーは、通常の JBoss EAP メッセージング接続をクライアントに送信、およびクラスター接続を介して他のサーバーに送信されます。ただし、最初の接続を確立する方法が必要です。これを行うには、UDP や JGroups などの動的な検出技術を使用するか、初期コネクターの 静的リスト を指定します。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <broadcast-group name="my-broadcast-group" connectors="http-connector" socket-binding="messaging-group"/>
    ...
  </server>
</subsystem>
...
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
  ...
  <socket-binding name="messaging-group" interface="private" port="5432" multicast-address="231.7.7.7" multicast-port="9876"/>
  ...
</socket-binding-group>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <broadcast-group name="my-broadcast-group" connectors="http-connector" jgroups-cluster="activemq-cluster"/>
    ...
  </server>
</subsystem>

/subsystem=messaging-activemq/server=default/broadcast-group=my-broadcast-group:add(connectors=[http-connector],jgroups-cluster=activemq-cluster)

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <discovery-group name="my-discovery-group" refresh-timeout="10000" socket-binding="messaging-group"/>
    ...
  </server>
</subsystem>
...
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
  ...
  <socket-binding name="messaging-group" interface="private" port="5432" multicast-address="231.7.7.7" multicast-port="9876"/>
  ...
</socket-binding-group>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <discovery-group name="my-discovery-group" refresh-timeout="10000" jgroups-cluster="activemq-cluster"/>
    ...
  </server>
</subsystem>

/subsystem=messaging-activemq/server=default/discovery-group=my-discovery-group:add(refresh-timeout=10000,jgroups-cluster=activemq-cluster)

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
    ...
  </server>
</subsystem>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
    ...
  </server>
</subsystem>

final String groupAddress = "231.7.7.7";
final int groupPort = 9876;

ServerLocator factory =
  ActiveMQClient.createServerLocatorWithHA(new DiscoveryGroupConfiguration(
      groupAddress,
      groupPort,
      new UDPBroadcastGroupConfiguration(groupAddress, groupPort, null, -1)));
ClientSessionFactory factory = locator.createSessionFactory();
ClientSession session1 = factory.createSession();
ClientSession session2 = factory.createSession();

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <connection-factory name="MyConnectionFactory" entries="..." connectors="http-connector http-node1 http-node2"/>
    ...
  </server>
</subsystem>

HashMap<String, Object> map = new HashMap<String, Object>();
map.put("host", "myhost");
map.put("port", "8080");

HashMap<String, Object> map2 = new HashMap<String, Object>();
map2.put("host", "myhost2");
map2.put("port", "8080");

TransportConfiguration server1 = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
TransportConfiguration server2 = new TransportConfiguration(NettyConnectorFactory.class.getName(), map2);

ServerLocator locator = ActiveMQClient.createServerLocatorWithHA(server1, server2);
ClientSessionFactory factory = locator.createSessionFactory();
ClientSession session = factory.createSession();

クラスター接続がクラスターのノード間で定義されている場合、JBoss EAP メッセージングはクライアントから特定ノードに到達するメッセージを負荷分散します。

メッセージングクラスター接続は、一致するコンシューマーが他のノードにあるかどうかに関係なく、ラウンドロビン方式でメッセージを負荷分散するように設定できます。一致するコンシューマーが存在する場合にのみ、他のノードに分散するように設定することもできます。詳細は、メッセージ再分配 セクションを参照してください。

クラスター接続の設定

クラスター接続はサーバーをクラスターにグループ化します。このため、クラスターのノード間でメッセージの負荷を分散できます。クラスター接続は、cluster-connection 要素を使用して JBoss EAP サーバー設定に定義します。

以下は、*-full プロファイルおよび *-full-ha プロファイルで定義されているデフォルトの cluster-connection です。属性の詳細リストは、クラスター接続の属性 を参照してください。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <cluster-connection name="my-cluster" discovery-group="dg-group1" connector-name="http-connector" address="jms"/>
    ...
  </server>
</subsystem>

上記の場合、クラスター接続は jms から始まるアドレスに送信されるメッセージを負荷分散します。このクラスター接続は、サブ文字列 jms から始まるコアキューにマップされるので、すべての JMS キューおよびトピックに適用されます。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <cluster-connection name="my-cluster" static-connectors="server0-connector server1-connector" .../>
    ...
  </server>
</subsystem>

重複検出のためのクラスター接続の設定

クラスター接続は、クラスターのノード間でメッセージを移動するために内部的に コアブリッジ を使用します。重複メッセージ検出にクラスター接続を設定するには、use-duplicate-detection 属性を true (デフォルト値) に設定します。

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:write-attribute(name=use-duplicate-detection,value=true)

クラスターユーザーの認証情報

クラスターのノード間で接続を作成し、クラスター接続を形成するとき、JBoss EAP メッセージングはクラスターのユーザーとパスワードを使用します。

以下の管理 CLI コマンドを使用して、クラスターのユーザーとパスワードを設定できます。

/subsystem=messaging-activemq/server=default:write-attribute(name=cluster-user,value="NewClusterUser")
/subsystem=messaging-activemq/server=default:write-attribute(name=cluster-password,value="NewClusterPassword123")

これにより、以下の XML コンテンツが JBoss EAP 設定ファイルの messaging-activemq サブシステムに追加されます。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <cluster user="NewClusterUser" password="NewClusterPassword123"/>
    ...
  </server>
</subsystem>

/subsystem=messaging-activemq/server=default:write-attribute(name=cluster-credential-reference,value={clear-text=SecretStorePassword})

JBoss EAP メッセージングのクライアント側のロードバランシングでは、単一のセッションファクトリーを使用して作成される後続のセッションをクラスターの異なるノードに接続できます。これにより、セッションがクラスターのノードにスムーズに広がり、特定のノードに集中することがありません。

クライアントファクトリーによって使用されるロードバランシングポリシーを宣言するための推奨される方法は、<connection-factory> リソースの connection-load-balancing-policy-class-name 属性を設定することです。JBoss EAP メッセージングでは、以下の追加設定なしのロードバランシングポリシーが提供され、独自のロードバランシングも実装できます。

また、org.apache.activemq.artemis.api.core.client.loadbalance.ConnectionLoadBalancingPolicy インターフェイスを実装して、独自のポリシーを実装することもできます。

メッセージ再分配では、コンシューマーのないキューから、クラスター内で、一致するコンシューマーを持つ他のノードにメッセージを自動的に再分配するように JBoss EAP メッセージングを設定できます。この機能を有効にするには、クラスター接続の message-load-balancing-type を ON_DEMAND (デフォルト値) に設定する必要があります。これは、以下の管理 CLI コマンドを使用して設定できます。

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:write-attribute(name=message-load-balancing-type,value=ON_DEMAND)

メッセージ再分配は、キューの最後のコンシューマーが閉じられた直後に起動するように、または、キューの最後のコンシューマーが閉じられてから再分配するまで、設定可能な遅延時間を待機するように設定できます。これは redistribution-delay 属性を使用して設定します。

redistribution-delay 属性を使用して、キューで最後のコンシューマーが閉じられてから、一致するコンシューマーを持つクラスターの他のノードにそのキューからメッセージを再分配するまでの待機時間 (ミリ秒) を設定します。-1 (デフォルト値) は、メッセージが再分配されないことを意味します。値が 0 の場合は、メッセージが即座に再分配されることを意味します。

デフォルトの JBoss EAP 設定の address-setting は redistribution-delay 値を 1000 に設定します。これは、メッセージを再分配する前に 1000 ミリ秒待機することを意味します。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
    ...
  </server>
</subsystem>

コンシューマーが閉じても、同じキューに別のコンシューマーがすぐに作成されることがよくあるため、多くの場合、再分配前に遅延を導入するのが理にかなっています。この場合、新しいコンシューマーがすぐに到達するため、即座の再分配は好ましくないでしょう。

以下は、jms から始まるアドレスにバインドされているキューまたはトピックに対して 0 の redistribution-delay を設定する address-setting の例です。この場合、メッセージは即座に再分配されます。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <address-setting name="jms.#" redistribution-delay="0"/>
    ...
  </server>
</subsystem>

このアドレス設定は、以下の管理 CLI コマンドを使用して追加できます。

/subsystem=messaging-activemq/server=default/address-setting=jms.#:add(redistribution-delay=1000)

クラスター化されたグループ化では、通常の メッセージのグループ化 に対して異なる方法を実行します。クラスターの中では、特定のグループ ID を持つメッセージグループが、ノードのいずれかに到達できます。ノードでは、どのノードの、どのコンシューマーに、どのグループ ID がバインドされるかを判断することが重要です。各ノードは、メッセージグループがデフォルトで到達する場所に関係なく、それらのグループ ID を処理するコンシューマーを持つノードにメッセージグループを正しくルーティングするロールを担います。指定したグループ ID を持つメッセージが、クラスター内の指定したノードに接続されている特定のコンシューマーに送信されます。この場合、これらのメッセージはコンシューマーが切断されても別のノードに送信されることはありません。

この状況は、グルーピングハンドラーによって処理されます。各ノードにグルーピングハンドラーがあります。また、このグルーピングハンドラー (と他のハンドラー) は、メッセージグループを正しいノードにルーティングするロールを担います。グルーピングハンドラーには、LOCAL と REMOTE の 2 つのタイプがあります。

ローカルハンドラーは、メッセージグループが取るルートを決定するロールを担います。リモートハンドラーはローカルハンドラーと通信し、適切に動作します。各クラスターは、特定のノードを選択してローカルグルーピングハンドラー指定するようにします。また、その他のすべてのノードには、リモートハンドラー指定する必要があります。

最初にメッセージグループを受信するノードが、通常のクラスタールーティング条件 (ラウンドロビンキューを利用できるか) に基づいてルーティングの決定を行います。ノードは、この決定をそれぞれのグルーピングハンドラーに提案します。グルーピングハンドラーが受け入れた場合は、提案されたキューにメッセージをルーティングします。

グルーピングハンドラーが提案を拒否した場合は、他のルートを提案し、それに応じてルーティングを行います。その他のノードも先例に従い、選択したキューにメッセージグループを転送します。メッセージがキューに到達すると、そのキューのカスタマーに固定されます。

管理 CLI を使用してグルーピングハンドラーを設定できます。以下のコマンドは、news.europe.# アドレスを使用して LOCAL グルーピングハンドラーを追加します。

/subsystem=messaging-activemq/server=default/grouping-handler=my-group-handler:add(grouping-handler-address="news.europe.#",type=LOCAL)

サーバーをリロードする必要があります。

reload

以下の表は、grouping-handler の設定可能な属性を示しています。

JBoss EAP 7.3 サーバーを設定して ActiveMQ Artemis クラスターを形成する場合は、実行中のクラスター化サーバーに接続されているその他のサーバーとクライアントが存在する可能性があります。接続されているクライアントおよびサーバーを最初にシャットダウンしてから、クラスター内で実行している JBoss EAP 7.3 サーバーをシャットダウンすることが推奨されます。これは順番に行う必要があり、サーバーがすべての接続を切断するのに十分な時間を設け、切断の際に、一貫性のない状態につながる可能性のある障害が発生するのを回避するためにも、並行して行ってはいけません。ActiveMQ Artemis はクラスターノードの自動スケールダウンに対応しておらず、すべてのクラスターノードが再起動されることを想定しています。

サーバーを起動するときにも同じことが当てはまります。ActiveMQ Artemis クラスターの JBoss EAP 7.3 サーバーを最初に起動する必要があります。起動が完了すれば、そのクラスターに接続する他のサーバーおよびクライアントを起動できます。

JBoss EAP 7 メッセージングにより、各ライブサーバーがバックアップを持つライブ/バックアップペアとしてサーバーをリンクできます。ライブサーバーはクライアントからメッセージを受信し、バックアップサーバーはフェイルオーバーが発生するまで機能しません。バックアップサーバーは 1 つのライブサーバーのみが所有でき、パッシブモードで留まり、ライブサーバーの作業の引き継ぎを待ちます。

ライブサーバーがクラッシュするか、正しいモードで停止した場合、現在パッシブモードのバックアップサーバーが新しいライブサーバーになります。新しいライブサーバーが、自動フェイルバックを許可するように設定されている場合は、古いライブサーバーが復旧することを検出して自動的に停止し、古いライブサーバーがメッセージの受信を再び開始できるようにします。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-attribute(name=synchronized-with-backup)

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:read-attribute(name=synchronized-with-live)

JBoss EAP メッセージングは、サーバーをバックアップする 2 つの異なるストラテジーであるレプリケーションと共有ストアをサポートしています。server 設定要素の ha-policy 属性を使用して、指定したサーバーに選択したポリシーを割り当てます。ha-policy には、4 つの有効な値があります。

ご覧のとおり、この値はサーバーが データのレプリケーション または 共有ストア の ha ポリシーを使用するかどうか、マスターまたはスレーブのロールを引き受けるかどうかを指定します。

管理 CLI を使用して、選択したサーバーに ha-policy を追加します。

/subsystem=messaging-activemq/server=SERVER/ha-policy=POLICY:add

たとえば、以下のコマンドを使用して replication-master ポリシーを デフォルト のサーバーに追加します。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add

replication-master ポリシーはデフォルト値で設定されます。ポリシーの追加時に、デフォルトの設定をオーバーライドする値を含めることができます。現在の設定を読み取る管理 CLI コマンドは、以下の基本構文を使用します。

/subsystem=messaging-activemq/server=SERVER/ha-policy=POLICY:read-resource

たとえば、以下のコマンドを使用して、上記を default のサーバーに追加された replication-master ポリシーの現在の設定を読み取ります。また、デフォルト設定を強調表示するために出力が含まれています。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-resource

{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => undefined,
        "group-name" => undefined,
        "initial-replication-sync-timeout" => 30000L
    }
}

各ポリシーで利用可能な設定オプションの詳細については、データのレプリケーション と 共有ストア を参照してください。

レプリケーションを使用すると、ライブとバックアップサーバーのペアが同じデータディレクトリーを共有せず、すべてのデータ同期がネットワーク経由で行われます。したがって、ライブサーバーが受信したすべての (永続的な) データがバックアップに複製されます。

ライブサーバーが正常にシャットダウンされると、バックアップサーバーがアクティブになり、クライアントはバックアップにフェイルオーバーします。この動作は事前に決定し、データのレプリケーション使用時に設定することはできません。

バックアップサーバーは、最初にライブサーバーのすべての既存データを同期してから置き換える必要があります。したがって、共有ストレージとは異なり、複製バックアップは、起動直後に完全に機能する訳ではありません。同期にかかる時間は、同期されるデータ量とネットワーク速度によって異なります。また、バックアップが起動すると、クライアントは initial-replication-sync-timeout の間ブロックされることに注意してください。このタイムアウトが過ぎると、同期が完了しない場合でもクライアントのブロックが解除されます。

フェイルオーバーが成功すると、バックアップのジャーナルは、ライブサーバーのデータよりも新しいデータの保持を開始します。フェイルバックを実行し、再起動後にライブサーバーになるように元のライブサーバーを設定できます。フェイルバックは、ライブサーバーがオンラインに戻る前に、バックアップサーバーとライブサーバーの間でデータを同期します。

両方のサーバーがシャットダウンしている場合、管理者はどのサーバーのジャーナルに最新データがあるかを判断する必要があります。バックアップジャーナルに最新のデータがある場合は、そのジャーナルをライブサーバーにコピーします。最新データがない場合は、再度アクティブになるたびに、バックアップはライブサーバーから古いジャーナルデータを複製し、独自のジャーナルデータを削除します。ライブサーバーのデータが最新の場合、アクションは不要で、サーバーを正常に起動できます。

ライブとバックアップの複製ペアは、クラスターの一部である必要があります。cluster-connection 設定要素は、バックアップサーバーがライブ一致を見つける方法を定義します。

レプリケーションには、ネットワーク分離のリスクを軽減するには、少なくとも 3 つのライブ/バックアップペアが必要ですが、このリスクを排除することはできません。3 つ以上のライブ/バックアップのペアを使用する場合、クラスターはクォーラム voting を使用して 2 つのライブブローカーを使用しないようにすることができます。

cluster-connection を設定する場合は、以下の詳細を確認してください。

<master> および <slave> 要素の両方に group-name 属性を設定して、ライブ/バックアップサーバーのペアを指定 し ます。バックアップサーバーは、同じ group-name を共有するライブサーバーにのみ接続します。

group-name を使用する例として、ライブサーバーと 3 つのバックアップサーバーがあるとします。ライブサーバーはそれぞれ独自のバックアップとペアする必要があるため、以下のグループ名を割り当てます。

上記の例では、サーバー backup1 は同じ group-name、pair1 でライブサーバーを検索します。この場合は、サーバーは live1 です。

共有ストアの場合と同様に、ライブサーバーが停止またはクラッシュすると、複製するペアのバックアップがアクティブになり、そのロールを引き継ぎます。特に、ライブサーバーへの接続が失われると、ペアのバックアップがアクティブになります。これは、一時的なネットワークの問題が原因でも発生することがあるため、問題となる可能性があります。この問題に対処するために、ペアのバックアップは、クラスター内の他のサーバーにまだ接続できるかどうかを判断しようとします。半分を超えるサーバーに接続できる場合、アクティブになります。ライブサーバーのほか、クラスター内の半分を超える他のサーバーとの通信が失われた場合、ペアのバックアップは待機し、ライブサーバーとの再接続を試みます。これにより、バックアップサーバーとライブサーバーの両方がメッセージを処理し、一方がそれに気付かないスプリットブレイン状況のリスクが軽減されます。

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:write-attribute(name=restart-backup,value=true)

AMQ222207: The backup server is not responding promptly introducing latency beyond the limit. Replication server being disconnected now.

このスタイルの高可用性は、ライブノードとバックアップノードの両方からアクセス可能な共有ファイルシステムを必要とするという点で、データのレプリケーションとは異なります。つまり、サーバーのペアは、設定の ページング、メッセージジャーナル、バインディングジャーナル、および 大きいメッセージ に同じ場所を使用します。

また、クラスターに含まれていない場合でも、ペアの各参加サーバー (ライブとバックアップ) には cluster-connection が定義されている必要があります。これは、cluster-connection で、バックアップサーバーがその存在をライブサーバーと他のすべてのノードに通知する方法を定義するからです。これがどのように実行されるかについては、クラスター接続の設定 を参照してください。

フェイルオーバーが発生し、バックアップサーバーが引き継ぐ場合、クライアントが接続できるようになるには、その前に、共有ファイルシステムから永続ストレージを読み込む必要があります。このスタイルの高可用性は、ライブとバックアップの両方のペアからアクセス可能な共有ファイルシステムを必要とするという点で、データのレプリケーションとは異なります。これは通常、ある種の高パフォーマンスストレージエリアネットワーク (SAN) になります。Red Hat は、ストレージソリューションに NAS と呼ばれるネットワーク接続ストレージの使用を推奨していません。

共有ストアの高可用性の利点は、ライブノードとバックアップノード間でレプリケーションが発生しないことです。これは、通常の操作中にレプリケーションのオーバーヘッドによるパフォーマンスの低下が発生しないことを意味します。

共有ストアのレプリケーションの欠点は、バックアップサーバーがアクティブになったときに、共有ストアからジャーナルをロードする必要があり、ストア内のデータ量によっては時間がかかる場合があることです。また、JBoss EAP でサポートされる共有ストレージソリューションが必要です。

通常の操作中に最高のパフォーマンスが必要な場合、Red Hat では、高性能な SAN にアクセスし、若干遅いフェイルオーバーコストを受け入れることを推奨しています。正確なコストは、データ量によって異なります。

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=restart-backup,value=true)

ライブサーバーに障害が発生し、バックアップがそのロールを引き継いだ後は、ライブサーバーを再起動して、クライアントをフェイルバックさせることができます。

共有ストアの場合は、単に元のライブサーバーを再起動し、プロセス自体を強制終了して新しいライブサーバーを強制終了します。または、スレーブで allow-fail-back を true に設定して、マスターがオンラインに戻ったら自動的に停止するように強制できます。allow-fail-back を設定する管理 CLI コマンドは以下のようになります。

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=allow-fail-back,value=true)

レプリケーション HA モードでは、マスター設定で check-for-live-server 属性が true に設定されていることを確認する必要があります。JBoss EAP 7.1 より、これがデフォルト値になります。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:write-attribute(name=check-for-live-server,value=true)

true に設定すると、ライブサーバーは、その nodeID を使用して別のサーバーの起動時にクラスターを検索します。見つかった場合は、このサーバーにアクセスし、フェイルバックを試行します。これはリモートのレプリケーションのシナリオであるため、元のライブサーバーは、その ID で実行しているバックアップとデータを同期する必要があります。同期されると、アクティブな処理を引き継ぐことができるようにするため、シャットダウンするようにバックアップサーバーに要求します。この動作により、元のライブサーバーは、フェイルオーバーがあったかどうかを判断して、フェイルオーバーがあった場合は、そのロールを果たしたサーバーがまだ実行中かどうかを判断できます。

共有ストアの場合、通常のサーバーシャットダウンでフェイルオーバーを発生させることができ、次のようにマスターまたはスレーブのいずれかの HA 設定でこの failover-on-server-shutdown を true に設定することもできます。

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=failover-on-server-shutdown,value=true)

また、allow-failback を true に設定することにより、元のライブサーバーが復旧したときに実行中のバックアップサーバーを強制的にシャットダウンし、元のライブサーバーが自動的に引き継げるようにできます。

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=allow-failback,value=true)

JBoss EAP では、バックアップメッセージングサーバーを、別のライブサーバーと同じ JVM にコロケートすることもできます。たとえば、各ライブサーバーが他のバックアップをコロケートするスタンドアロンサーバーの単純な 2 ノードクラスターの例を考えましょう。このようにサーバーをコロケートする場合、共有ストアまたは複製された HA ポリシーのいずれかを使用できます。コロケートするようにメッセージングサーバーを設定する際に覚えておくべき 2 つの重要なことがあります。

第 1 に、設定の各 server 要素には、独自の remote-connector および remote-acceptor、または http-connector および http-acceptor が必要です。たとえば、remote-acceptor を使用するライブサーバーは、ポート 5445 でリッスンするよう設定できますが、コロケートされたバックアップからの remote-acceptor はポート 5446 を使用します。ポートは、デフォルトの socket-binding-group に追加する必要がある socket-binding 要素に定義します。http-acceptors の場合、ライブおよびコロケートバックアップは、同じ http-listener を共有できます。各 server 設定のクラスター関連の設定要素は、サーバーによって使用される remote-connector または http-connector を使用します。関連する設定が、後述の各例に含まれています。

第 2 に、ジャーナル関連のディレクトリーのパスを適切に設定する点に注意します。たとえば、共有ストアのコロケートトポロジーでは、ライブサーバーとそのバックアップの両方が、別のライブサーバーにコロケーションされ、バインディング と メッセージ ジャーナル用、大きいメッセージ 用、ページング 用にディレクトリーの場所を共有するように設定する必要があります。

JBoss EAP のメッセージングは、2 つのタイプのクライアントフェイルオーバーを定義します。

また、JBoss EAP メッセージングでは、同じサーバーに対して 100% 透過的な自動再割り当てを提供します (一時的なネットワークの問題の場合など)。これは、同じサーバーに再接続される点を除くと、フェイルオーバーと似ています。詳細は、クライアントの再接続とセッションの再割り当て を参照してください。

フェイルオーバー中に、クライアントのコンシューマーが非永続的または一時的なキューにある場合、これらのキューはバックアップノード上でフェイルオーバー中に自動的に再作成されます。これは、バックアップノードが非永続キューを認識しないためです。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-resource

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=reconnect-attempts,value=<NEW_VALUE>)

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=initial-connect-attempts,value=<NEW_VALUE>)

このセクションでは、接続の Time-to-Live (TTL) について説明します。また、JBoss EAP メッセージングが、クラッシュしたクライアントおよびリソースを正常にクローズせずに終了したクライアントを処理する方法についても説明します。

サーバー上の使用済みの接続リソースのクリーンアップ

JBoss EAP クライアントアプリケーションが終了する前に、finally ブロックを使用して制御された方法で、そのリソースを閉じる必要があります。

以下は、コアクライアントが finally ブロックでセッションとセッションファクトリーを適切に閉じる例です。

ServerLocator locator = null;
ClientSessionFactory sf = null;
ClientSession session = null;

try {
   locator = ActiveMQClient.createServerLocatorWithoutHA(..);

   sf = locator.createClientSessionFactory();;

   session = sf.createSession(...);

   ... do some stuff with the session...
}
finally {
   if (session != null) {
      session.close();
   }

   if (sf != null) {
      sf.close();
   }

   if(locator != null) {
      locator.close();
   }
}

以下は、適切に動作する JMS クライアントアプリケーションの例です。

Connection jmsConnection = null;

try {
   ConnectionFactory jmsConnectionFactory = ActiveMQJMSClient.createConnectionFactoryWithoutHA(...);

   jmsConnection = jmsConnectionFactory.createConnection();

   ... do some stuff with the connection...
}
finally {
   if (connection != null) {
      connection.close();
   }
}

ただし、クライアントがクラッシュし、リソースを消去する機会がない場合もあります。これが発生すると、サーバー側のリソースがサーバー上でハングしたままになる可能性があります。これらのリソースを削除しないと、サーバーでリソースリークが発生し、時間が経つにつれてサーバーでメモリーまたは他のリソースが不足する可能性があります。

使用済みのクライアントリソースを消去しようとする場合、重要なことは、クライアントとサーバー間のネットワークに障害が発生した後に復帰し、クライアントが再接続できるという事実を認識することです。JBoss EAP はクライアントの再接続に対応しているため、サーバー側の使用済みのリソースをすぐに消去しないようにすることが重要です。そうしないと、クライアントがサーバー上の古いセッションに再接続してリソースを取り戻すことができなくなります。

JBoss EAP は、これらすべてを設定可能にします。ClientSessionFactory の設定ごとに、Time-To-Live (TTL) プロパティーを使用して、クライアントからのデータがない場合にサーバーが接続を有効に保つ時間 (ミリ秒単位) を設定できます。クライアントは、サーバーが接続を閉じないように、定期的に ping パケットを自動的に送信します。サーバーが TTL 時間の間に接続でパケットを受信しない場合、その接続に関連するサーバー上のすべてのセッションを自動的に閉じます。

JMS を使用している場合、接続 TTL は ActiveMQConnectionFactory インスタンスの ConnectionTTL 属性によって定義されます。または、JMS 接続ファクトリーインスタンスをサーバー側の JNDI に直接デプロイする場合は、パラメーター connectionTtl を使用して xml 設定に指定できます。

http-connector などのネットワークベース接続の ConnectionTTL のデフォルト値は 60000 (1 分) です。in-vm など、内部接続の接続 TTL のデフォルト値は -1 です。ConnectionTTL の -1 の値は、サーバーが、サーバー側で接続をタイムアウトしないことを意味します。

クライアントが独自の接続 TTL を指定しないようにするには、サーバー側でグローバル値を設定します。これを行うに、サーバー設定に connection-ttl-override 属性を指定します。connection-ttl-override のデフォルト値は -1 です。これはオーバーライドしない、つまり、クライアントが独自の値を使用できることを意味します。

コアセッションまたは JMS 接続を閉じる

すべてのコアクライアントセッションと JMS 接続は、使用の終了時に常に finally ブロックで明示的に閉じられていることが重要です。

これができない場合、JBoss EAP はガベージコレクション時にこれを検出します。その後、接続を閉じ、以下のような警告をログに記録します。

[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession]  I'm closing a ClientSession you left open. Please make sure you close all ClientSessions explicitly before let
ting them go out of scope!
[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession]  The session you didn't close was created here:
java.lang.Exception
   at org.apache.activemq.artemis.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
   at org.acme.yourproject.YourClass (YourClass.java:666)

JMS を使用している場合、警告は、クライアントセッションではなく、JMS 接続を伴うことに注意してください。また、ログには、閉じられていない JMS 接続またはコアクライアントセッションがインスタンス化されたコードの正確な行が示されます。これにより、コード内のエラーを特定し、適切に修正できます。

クライアント側からの障害の検出

クライアントは、サーバーからデータを受信している限り、接続は有効であると見なします。クライアントが client-failure-check-period ミリ秒のパケットを受信しない場合は、接続が失敗したと見なし、フェイルオーバーを開始するか、クライアントの設定方法に応じて、FailureListener インスタンスまたは ExceptionListener インスタンスを呼び出します。

JMS を使用している場合、この動作は、ActiveMQConnectionFactory インスタンスの ClientFailureCheckPeriod 属性で定義します。

HTTP 接続など、ネットワーク接続におけるクライアント障害チェックの間隔のデフォルト値は 30000 (30 秒) です。in-vm 接続のクライアント障害チェックの間隔のデフォルト値は -1 です。-1 の値は、サーバーからデータが受信されない場合、クライアントがクライアント側で接続に失敗しないことを意味します。接続のタイプに関係なく、一時的な障害が発生した場合にクライアントが再接続できるように、チェックの間隔は通常、サーバー上の接続 TTL の値よりもはるかに短くします。

非同期接続実行の設定

サーバー側で受信されたパケットの多くは、リモーティング スレッドで実行されます。これらのパケットは短時間実行される操作を表し、パフォーマンス上の理由から常に リモーティング スレッドで実行されます。

ただし、デフォルトでは、一部のパケットはスレッドプールからスレッドを使用して実行され、リモーティング スレッドが長時間固定されないようにします。別のスレッドで操作を非同期に処理すると、待ち時間が少し長くなることに注意してください。これらのパケットは、以下のとおりです。

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.RollbackMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionCloseMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionCommitMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionXACommitMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionXAPrepareMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionXARollbackMessage

非同期接続実行を無効にするには、パラメーター async-connection-execution-enabled を false に設定します。デフォルト値は true です。

JBoss EAP メッセージングクライアントは、クライアントとサーバー間の接続で障害が検出された場合に、自動的にサーバーに再接続または再割り当てするように設定できます。

透過的なセッションの再割り当て

ネットワークの一時停止のように一時的な原因で障害が発生し、ターゲットサーバーが再起動されなかった場合、connection-ttl の値より長い間、クライアントが切断されることはないと仮定して、セッションはサーバー上に残ります。使用済みの接続の検出 を参照してください。

このシナリオでは、再接続が確立されたときに、JBoss EAP がクライアントセッションをサーバーセッションに自動的に再割り当てします。これは 100% 透過的に行われ、クライアントは何も起こらなかったようにそのまま続行できます。

JBoss EAP メッセージングクライアントがサーバーにコマンドを送信すると、送信された各コマンドはインメモリーバッファーに保存されます。接続が失敗し、その後クライアントが再割り当てプロトコルの一部として同じサーバーに再割り当てを試みると、サーバーは正常に受信した最後のコマンドの ID をクライアントに提供します。

クライアントがフェイルオーバー前に受信したよりも多くのコマンドを送信した場合、クライアントとサーバーが状態を回復できるように、送信されたコマンドをバッファーから再生できます。

このバッファーのサイズ (バイト単位) は、confirmationWindowSize プロパティーで設定します。サーバーが confirmationWindowSize バイトのコマンドを受信して処理すると、コマンド確認をクライアントに送り返し、クライアントはバッファー内のスペースを解放できます。

サーバー上で JMS サービスを使用して JMS 接続ファクトリーインスタンスを JNDI にロードする場合、選択した connection-factory の confirmation-window-size 属性を設定して、サーバー設定にこのプロパティーを設定できます。JMS を使用し、JNDI を使用しない場合、適切なセッターメソッド setConfirmationWindowSize を使用して ActiveMQConnectionFactory インスタンスにこれらの値を直接設定できます。コア API を使用している場合、ServerLocator インスタンスには、公開された setConfirmationWindowSize メソッドもあります。

confirmationWindowSize を -1 (デフォルト) に設定すると、バッファーリングが無効になり、再割り当てが発生しないようになり、代わりに再接続が強制されます。

セッション再接続

または、サーバーがクラッシュ後に実際に再起動されたか、停止されている可能性があります。このような場合、セッションはサーバー上に存在しなくなり、100% 透過的にそれらに再割り当てることができなくなります。

この場合、JBoss EAP は自動的に接続を再接続し、クライアント上のセッションおよびコンシューマーに対応するサーバー上でセッションとコンシューマーを再作成します。このプロセスは、バックアップサーバーにフェイルオーバーする際に発生するプロセスとまったく同じです。

また、クライアントの再接続は、コアブリッジなどのコンポーネントがターゲットサーバーに再接続できるように、内部的に使用されます。

再接続中にトランザクションセッションと非トランザクションセッションが再接続される方法と、1 回限りの配信保証を維持するために必要な事項を完全に理解するには、自動クライアントフェイルオーバー のセクションを参照してください。

再接続属性の設定

クライアントの再接続を設定するには、以下のプロパティーを設定します。

クライアント上で JMS および JNDI を使用して JMS 接続ファクトリーインスタンスを検索する場合は、これらのパラメーターを JNDI コンテキスト環境で指定できます。たとえば、jndi.properties ファイルは以下のようになります。

java.naming.factory.initial = ActiveMQInitialContextFactory
connection.ConnectionFactory=tcp://localhost:8080?retryInterval=1000&retryIntervalMultiplier=1.5&maxRetryInterval=60000&reconnectAttempts=1000

JMS を使用し、JMS 接続ファクトリーを直接インスタンス化する場合は、作成直後に ActiveMQConnectionFactory で適切なセッターメソッドを使用してパラメーターを指定できます。

コア API を使用して、ServerLocator インスタンスを直接インスタンス化する場合は、作成直後に ServerLocator で適切なセッターメソッドを使用してパラメーターを指定することもできます。

クライアントは再接続できるが、サーバーが再起動したかタイムアウトした場合など、サーバーでセッションが使用できなくなった場合、クライアントは再割り当てできず、接続またはセッションに登録されている ExceptionListener または FailureListener インスタンスが呼び出されます。

ExceptionListeners と SessionFailureListeners

クライアントが再接続または再割り当てすると、登録されている JMS ExceptionListener またはコア API SessionFailureListener が呼び出されます。

JBoss EAP 7 には統合された Artemis リソースアダプターが含まれており、これは pooled-connection-factory 要素を使用してリソースアダプターの送受信接続を設定します。

送信接続

送信接続は、pooled-connection-factory 要素を使用して定義します。これは、Jakarta Enterprise Beans およびサーブレットによって Jakarta EE デプロイメントで使用され、キューまたはトピックからメッセージを送受信します。接続ファクトリーから作成される接続はアプリケーションサーバーのスコープ内に作成されるため、以下のようにアプリケーションサーバー機能を使用できます。

これらの機能は、InVmConnectionFactory や RemoteConnectionFactory のような基本の connection-factory では使用できないため、これは pooled-connection-factory との大きな違いです。また、pooled-connection-factory を使用して定義される接続ファクトリーでは、外部スタンドアロン JMS クライアントから JNDI を使用してルックアップを行うことができないことに注意してください。

受信接続

受信接続は、メッセージ駆動 Bean (MDB) がキューまたはトピックからメッセージを受信するためにのみ使用されます。MDB は、キューまたはトピックをリッスンするステートレスセッション Bean です。onMessage(Message message) 公開メソッドを実装する必要があります。これは、メッセージがキューまたはトピックに送信されるときに呼び出されます。Artemis リソースアダプターは、キューまたはトピックからメッセージを受信して onMessage(Message message) メソッドに渡すロールを担います。この目的のため、受信接続を設定して、統合された Artemis サーバーの場所と追加要素を定義します。

各 MDB セッション Bean は、クライアントスレッドプールのスレッドを使用して、宛先からのメッセージを消費します。最大プールサイズが定義されていない場合は、CPU コアプロセッサー数の 8 倍になるように決定されます。テストスイートなど、多くの MDB セッションを持つシステムの場合、これによりスレッドが枯渇し、MDB がプールからの空きスレッドを待機するように強制する可能性があります。管理 CLI を使用して、クライアントスレッドプールの最大プールサイズを増やすことができます。以下のコマンドは、最大クライアントスレッドプールサイズを 128 に設定します。

/subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=128)

クライアントスレッドプールサイズを設定する方法は、クライアントスレッド管理 を参照してください。MDB に関する詳細は、JBoss EAP のDeveloping EJB Applicationsの Message Driven Beans を参照してください。

JBoss EAP には、統合 ActiveMQ Artemis メッセージングサーバーに接続するためのリソースアダプターが含まれています。デフォルトで、messaging-activemq サブシステムに定義された pooled-connection-factory はアダプターを使用して接続を確立します。ただし、同じリソースアダプターを使用して、JBoss EAP のリモートインスタンス内で実行している Artemis サーバーへの接続も確立できます。

WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"]

JBoss EAP のリモートインスタンス内で実行している Artemis サーバーに接続するには、以下の手順に従って新しい pooled-connection-factory を作成します。

MDB を pooled-connection-factory を使用するように設定する

pooled-connection-factory をリモート Artemis サーバーに接続するよう設定した後、リモートサーバーからメッセージを読み取るメッセージ駆動 Bean (MDB) では、pooled-connection-factory リソースの名前を使用して @ResourceAdapter アノテーションを付加する必要があります。

import org.jboss.ejb3.annotation.ResourceAdapter;

@ResourceAdapter("remote-artemis")
@MessageDriven(name = "MyMDB", activationConfig = { ... })
public class MyMDB implements MessageListener {
    public void onMessage(Message message) {
       ...
    }
}

MDB がリモートサーバーにメッセージを送信する必要がある場合は、JNDI エントリー の 1 つを使用して検索することにより、pooled-connection-factory を挿入する必要があります。

@Inject
@JMSConnectionFactory("java:/jms/remoteCF")
private JMSContext context;

JMS 宛先の設定

MDB は、メッセージを消費する宛先も指定する必要があります。これを実行するための標準的な方法は、ローカルサーバーの JNDI ルックアップに対応する destinationLookup アクティベーション設定プロパティーを定義することです。

@ResourceAdapter("remote-artemis")
@MessageDriven(name = "MyMDB", activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "myQueue"),
    ...
})
public class MyMDB implements MessageListener {
    ...
}

ローカルサーバーにリモート Artemis サーバーの JNDI バインディングが含まれない場合は、destination アクティベーション設定プロパティーを使用して、リモート Artemis サーバーに設定されているように宛先の名前を指定し、useJNDI アクティベーション設定プロパティーを false に設定します。これは、JNDI ルックアップを必要とせずに JMS 宛先を自動的に作成するように Artemis リソースアダプターに指示します。

@ResourceAdapter("remote-artemis")
@MessageDriven(name = "MyMDB", activationConfig = {
    @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"),
    @ActivationConfigProperty(propertyName = "destination", propertyValue = "myQueue"),
    ...
})
public class MyMDB implements MessageListener {
    ...
}

上記の例では、アクティベーション設定プロパティーは、リモート Artemis サーバーでホストされている myQueue という名前の JMS キューからメッセージを消費するように MDB を設定します。ほとんどの場合、MDB は、消費されたメッセージを処理するために他の宛先をルックアップする必要がなく、メッセージに定義されている場合は、JMSReplyTo 宛先を使用できます。

MDB でリモートサーバーに定義された他の JMS 宛先が必要な場合は、クライアント側 JNDI を使用する必要があります。詳細は、サーバーへの接続 を参照してください。

統合された Artemis リソースアダプターを Red Hat AMQ 7 のリモートインストールに接続するように設定できます。Red Hat AMQ 7 は、JBoss EAP 7.3 アプリケーションの JMS プロバイダーになります。これにより、JBoss EAP がリモート Red Hat AMQ 7 サーバーのクライアントになることができます。

AMQP や STOMP などの他のメッセージングプロトコルのサポートが必要な場合は、Red Hat AMQ 7 をメッセージングブローカーとして設定する必要があります。JBoss EAP サーバーに統合された Artemis リソースアダプターは、デプロイされたアプリケーションのメッセージを処理するために使用できます。

統合されたリソースアダプターの制限

キューとトピックの動的作成

JBoss EAP 7.3 に統合されている Artemis リソースアダプターは、Red Hat AMQ 7 ブローカーのキューとトピックの動的な作成をサポートしていないことに注意してください。すべてのキューとトピック宛先を、リモート Red Hat AMQ 7 サーバーに直接設定する必要があります。

接続ファクトリーの作成

Red Hat AMQ では、接続ファクトリーは pooled-connection-factory と external-context の両方を使用して設定できますが、各接続ファクトリーの作成方法には違いがあります。external-context を使用して接続ファクトリーを作成すると、JMS 仕様 に定義されている単純な JMS 接続ファクトリーが作成されます。新規作成された接続ファクトリーは RemoteConnectionFactory と同じで、これは messaging-activemq サブシステムにデフォルトで定義されています。この接続ファクトリーはアプリケーションサーバー内の他のコンポーネントから独立しているため、トランザクションマネージャーやセキュリティーマネージャーなどの他のコンポーネントを認識せず、使用することができません。このため、JBoss EAP 7 で接続ファクトリーを作成するには、pooled-connection-factory のみを使用できます。external-context は、ローカルデプロイメントが検索または挿入できるように、リモート AMQ 7 ブローカーですでに設定されている JMS 宛先を JBoss EAP 7 サーバーの JNDI ツリーに登録するためにのみ使用できます。

Artemis リソースアダプターを使用しないため、external-context または connection-factory 要素を設定して作成された接続ファクトリーを使用してリモート AMQ 7 ブローカーに接続することはできません。リモート AMQ 7 ブローカーに接続する場合は、pooled-connection-factory 要素を設定して作成される接続ファクトリーのみが、使用がサポートされます。

リモート Red Hat AMQ Server を使用するように JBoss EAP を設定する

管理 CLI を使用して、以下の手順に従って、メッセージングプロバイダーとして Red Hat AMQ 7 のリモートインストールを使用するように JBoss EAP を設定できます。

これで、JBoss EAP が Red Hat AMQ 7 のリモートインストールをメッセージングプロバイダーとして使用するよう設定されました。

管理 CLI から、@JMSConnectionFactoryDefinition アノテーションまたは @JMSDestinationDefinition アノテーションを使用して、Red Hat AMQ 7 などのリモート Artemis ベースのブローカーの JMS リソースを設定できます。管理コンソールからリソースを設定することもできます。

リモート ActiveMQ サーバーリソースは、Artemis のローカルインスタンスを必要としません。これにより、JBoss EAP イメージのメモリーと CPU フットプリントが削減されます。

Red Hat JBoss A-MQ 製品が提供するリソースアダプターをデプロイし、たとえば Red Hat JBoss A-MQ 6.3.0 を JBoss EAP の外部 JMS プロバイダーにすることができます。

Red Hat JBoss A-MQ リソースアダプターをデプロイおよび設定する方法の詳細は、Red Hat JBoss A-MQ ドキュメントスイート内にあるIntegrating with JBoss Enterprise Application Platformの Install the ActiveMQ Resource Adapter を参照してください。

IBM MQ について

IBM MQ は、IBM のメッセージ指向ミドルウェア (MOM) 製品で、分散システム上のアプリケーションが互いに通信できるようにします。これは、メッセージとメッセージキューを使用して実行できます。IBM MQ は、メッセージキューにメッセージを配信し、メッセージチャネルを使用してデータを他のキューマネージャーへ転送します。IBM MQ の詳細は、IBM の製品 Web サイトの IBM MQ を参照してください。

概要

IBM MQ は、JBoss EAP 7.3 の外部 JMS プロバイダーとして設定できます。このセクションでは、JBoss EAP で IBM MQ リソースアダプターをデプロイして設定する手順を説明します。このデプロイメントと設定は、管理 CLI ツールまたは Web ベースの管理コンソールを使用して実行できます。IBM MQ のサポートされる設定に関する最新情報は、JBoss EAP supported configurations を参照してください。

前提条件

作業を開始する前に、IBM MQ リソースアダプターのバージョンを検証し、その設定プロパティーを理解する必要があります。

手順

@ActivationConfigProperty(propertyName = "destination", propertyValue = "QUEUE")

@JMSConnectionFactoryDefinition(
    name = "java:/jms/WMQConnectionFactory",
    interfaceName = "javax.jms.ConnectionFactory",
    resourceAdapter = "wmq.jmsra",
    properties = {
        "channel=<channel>",
        "hostName=<hostname_wmq_broker>",
        "transportType=<transport_type>",
        "queueManager=<queue_manager>"
    }
)

@Inject
@JMSConnectionFactory("jms/CF")
@JMSPasswordCredential(userName="myusername", password="mypassword")
@JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE)
transient JMSContext context3;

WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (EJB default - 7) IJ000604: Throwable while attempting to get a new connection: null: com.ibm.mq.connector.DetailedResourceException: MQJCA1011: Failed to allocate a JMS connection., error code: MQJCA1011 An internal error caused an attempt to allocate a connection to fail. See the linked exception for details of the failure.

QueueConnection qc = queueConnectionFactory.createQueueConnection("invalidUserName", "invalidPassword");

SVR-ERROR: Expected JMSException, received com.ibm.mq.connector.outbound.MQQueueProxy cannot be cast to com.ibm.mq.jms.MQDestination

ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jmsServlet-1.0-SNAPSHOT/: com.ibm.msg.client.jms.DetailedJMSRuntimeException: MQJCA0002: An exception occurred in the IBM MQ layer. See the linked exception for details.
A call to IBM MQ classes for Java(tm) caused an exception to be thrown.

SVR-ERROR: com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ2007: Failed to send a message to destination 'MDB_NAME TOPIC_NAME'

com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2072' ('MQRC_SYNCPOINT_NOT_AVAILABLE')

WARN  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) IJ020017: Invalid archive: file:/<path-to-jboss>/jboss-eap-7.3/standalone/tmp/vfs/temp/tempa02bdd5ee254e590/content-135e13d4f38704fc/contents/

/subsystem=jca/archive-validation=archive-validation:write-attribute(name=enabled, value=false)

JBoss EAP は、サードパーティーの Jakarta Messaging プロバイダーと連携するように設定できます。ただし、Jakarta アプリケーションプラットフォームとの統合のために、すべての Jakarta Messaging プロバイダーが Jakarta Messaging Jakarta Connectors リソースアダプターを生成するわけではありません。この手順では、JBoss EAP に含まれる汎用 Jakarta Messaging リソースアダプターを設定して Jakarta Messaging プロバイダーに接続する手順を説明します。この手順では、Tibco EMS 8 を Jakarta Messaging プロバイダーの例として使用します。他の Jakarta Messaging プロバイダーでは、異なる設定が必要になる場合があります。

汎用リソースアダプターを設定する前に、以下を行う必要があります。

この手順で使用する XML の例では、これらのパラメーターはそれぞれ、PROVIDER_FACTORY_INITIAL、PROVIDER_URL、PROVIDER_CONNECTION_FACTORY として記述されています。これらのプレースホルダーを、お使いの環境の Jakarta Messaging の値に置き換えてください。

@MessageDriven(name = "HelloWorldQueueMDB", activationConfig = {
  // The generic Jakarta Messaging resource adapter requires the  Java Naming and Directory Interface bindings
  // for the actual remote connection factory and destination
  @ActivationConfigProperty(propertyName = "connectionFactory", propertyValue = "java:global/remoteJMS/XAQCF"),
  @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:global/remoteJMS/Queue1"),
  @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
  @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
  public class HelloWorldQueueMDB implements MessageListener {
  public void onMessage(Message message) {
  // called every time a message is received from the _Queue1_ queue on the Jakarta Messaging provider.
  }
}

@Resource(lookup = "java:/jms/XAQCF")
private ConnectionFactory cf;

@Resource(lookup = "java:global/remoteJMS")
private Context context;
...
Queue queue = (Queue) context.lookup("Queue1")

@Resource アノテーションを使用すると、Jakarta Enterprise Beans は Jakarta Messaging リソースまたは接続ファクトリーを直接挿入できます。@Resource アノテーションを使用して以下のパラメーターを指定できます。

リソースを挿入するには、これらのいずれかのパラメーターにリソースの Java Naming and Directory Interface (JNDI) 名を指定する必要があります。

前方互換性では、レガシー JBoss EAP 6 の JMS クライアントへのコード変更は必要ありません。サポートは JBoss EAP messaging-activemq サブシステムおよびそのリソースによって提供されます。前方互換性のサポートを有効にするには、JBoss EAP 7 サーバーの設定に以下の変更を行います。手順ごとに、スタンドアロンサーバーの管理 CLI コマンドの例を示します。

管理 CLI の移行操作

管理 CLI の migrate 操作を実行して messaging サブシステム設定を更新する場合、ブール値の引数 add-legacy-entries が true に設定されていると、messaging-activemq サブシステムは legacy-connection-factory リソースを作成し、legacy-entries を jms-queue および jms-topic リソースに追加します。移行された messaging-activemq サブシステムのレガシーエントリーは、レガシー messaging サブシステムに指定されたエントリーに対応し、通常のエントリーは -new 接尾辞を付加して作成されます。

migrate 操作の実行時にブール値の引数 add-legacy-entries が false に設定されていると、messaging-activemq サブシステムにはレガシーリソースが作成されず、レガシー JMS クライアントは JBoss EAP 7 サーバーと通信できません。

後方互換性では、レガシー JBoss EAP 7 サーバーの設定変更は必要ありません。JBoss EAP 7 の JMS クライアントはレガシーサーバー上でリソースを検索せず、代わりにクライアント側の JNDI を使用して JMS リソースを作成します。JBoss EAP 7 の JMS クライアントはこれらのリソースを使用して、HornetQ コアプロトコルを使用してレガシーサーバーと通信できます。

JBoss EAP メッセージングは、クライアント側 JNDI をサポートし、JMS ConnectionFactory および Destination リソースを作成します。

たとえば、JBoss EAP 7 の JMS クライアントが myQueue という名前の JMS キューを使用してレガシーサーバーと通信する場合は、以下のプロパティーを使用して JNDI InitialContext を設定する必要があります。

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connectionFactory.jms/ConnectionFactory=tcp://<legacy server address>:5445? \
    protocolManagerFactoryStr=org.apache.activemq.artemis.core.protocol.hornetq.client.HornetQClientProtocolManagerFactory
queue.jms/myQueue=myQueue

次に、クライアントは jms/ConnectionFactory 名を使用して JMS ConnectionFactory を作成し、jms/myQueue を使用して JMS Queue を作成できます。レガシー接続ファクトリーの URL を指定する場合、プロパティー protocolManagerFactoryStr=org.apache.activemq.artemis.core.protocol.hornetq.client.HornetQClientProtocolManagerFactory が必須であることに注意します。これにより、JBoss EAP メッセージング JMS クライアントはレガシーサーバーで HornetQ ブローカーと通信できます。

パフォーマンスに悪影響を及ぼす可能性があるため、messaging-activemq サブシステムの統計収集はデフォルトで有効になっていません。キューのメッセージ数やキューに追加されたメッセージ数など、基本情報を取得するためにキュー統計を有効にする必要はありません。これらの統計は、statistics-enabled を true に設定しなくてもキュー属性を使用して利用できます。

追加の統計収集は、管理 CLI または 管理コンソール を使用して有効にできます。

管理 CLI を使用したメッセージング統計の有効化

以下の管理 CLI コマンドは、default メッセージングサーバーの統計の収集を有効にします。

/subsystem=messaging-activemq/server=default:write-attribute(name=statistics-enabled,value=true)

プールされた接続ファクトリーの統計は、他のメッセージングサーバー統計とは別に有効になります。以下のコマンドを使用して、プールされた接続ファクトリーの統計を有効にします。

/subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=statistics-enabled,value=true)

変更を反映するためにサーバーをリロードします。

管理コンソールを使用したメッセージング統計の有効化

管理コンソールを使用してメッセージングサーバーの統計収集を有効にするには、以下の手順に従います。

プールされた接続ファクトリーの統計は、他のメッセージングサーバー統計とは別に有効になります。プールされた接続ファクトリーの統計収集を有効にするには、以下の手順に従います。

管理 CLI または 管理コンソール を使用して、メッセージングサーバーのランタイム統計を表示できます。

管理 CLI を使用したメッセージング統計の表示

以下の管理 CLI コマンドを使用するとメッセージング統計を表示できます。統計はラインタイム情報であるため、必ず include-runtime=true 引数を指定してください。

管理コンソールを使用したメッセージング統計の表示

管理コンソールからメッセージング統計を表示するには、ランタイムタブで Messaging (ActiveMQ) サブシステムに移動し、サーバーを選択します。統計を表示する宛先を選択します。

利用可能なすべての統計の詳細リストは、メッセージング統計 を参照してください。

メッセージングサーバーの以下のメッセージカウンター属性を設定できます。

これらのオプションを設定する管理 CLI コマンドは以下の構文を使用します。STATISTICS_NAME と STATISTICS_VALUE は、設定する統計の名前と値に置き換えてください。

/subsystem=messaging-activemq/server=default::write-attribute(name=STATISTICS_NAME,value=STATISTICS_VALUE)

たとえば、以下のコマンドを使用して message-counter-max-day-history を 5 日に設定し、message-counter-sample-period を 2 秒に設定します。

/subsystem=messaging-activemq/server=default:write-attribute(name=message-counter-max-day-history,value=5)
/subsystem=messaging-activemq/server=default:write-attribute(name=message-counter-sample-period,value=2000)

以下の管理 CLI 操作を使用して、キューのメッセージカウンターとメッセージカウンター履歴を表示できます。

これらの値の表示に使用する管理 CLI コマンドは、以下の構文を使用します。QUEUE_NAME と OPERATION_NAME は、使用するキュー名と操作に置き換えてください。

/subsystem=messaging-activemq/server=default/jms-queue=QUEUE_NAME:OPERATION_NAME

たとえば、以下のコマンドを使用して、JSON 形式で TestQueue キューのメッセージカウンターを表示します。

/subsystem=messaging-activemq/server=default/jms-queue=TestQueue:list-message-counter-as-json
{
    "outcome" => "success",
    "result" => "{\"destinationName\":\"TestQueue\",\"destinationSubscription\":null,\"destinationDurable\":true,\"count\":0,\"countDelta\":0,\"messageCount\":0,\"messageCountDelta\":0,\"lastAddTimestamp\":\"12/31/69 7:00:00 PM\",\"updateTimestamp\":\"2/20/18 2:24:05 PM\"}"
}

reset-message-counter 管理 CLI 操作を使用して、キューのメッセージカウンターをリセットできます。

/subsystem=messaging-activemq/server=default/jms-queue=TestQueue:reset-message-counter
{
    "outcome" => "success",
    "result" => undefined
}

管理コンソールを使用して、以下を操作できます。

別のメッセージングサーバーへの強制的なフェイルオーバーの実行

メッセージングサーバーのすべてのメッセージカウンターのリセット

メッセージングサーバーのメッセージカウンター履歴のリセット

メッセージングサーバーに関連する情報の表示

管理コンソールを使用して、メッセージングサーバーに関連する以下の情報の一覧を表示できます。

メッセージングサーバーに関連する情報を表示するには、以下を行います。

メッセージングサーバーの接続を閉じる

IP アドレス、ActiveMQ アドレス一致、またはユーザー名を指定して接続を閉じることができます。

メッセージングサーバーの接続を閉じるには、以下を行います。

メッセージングサーバーのロールバックトランザクション

メッセージングサーバーのトランザクションのコミット