AMQ JMS クライアントの使用

AMQ JMS は、以下の業界標準およびネットワークプロトコルをサポートします。

AMQ JMS でサポートされている設定については、Red Hat カスタマーポータルの「Red Hat AMQ 7 でサポートされる構成」を参照してください。

本セクションでは、コア API エンティティーを紹介し、それらが一緒に操作する方法を説明します。

AMQ JMS は メッセージを送受信します。メッセージは、メッセージプロデューサーとコンシューマーを使用して、接続されたピア間で転送されます。プロデューサーおよびコンシューマーは セッション 上で確立されます。セッションはコネクション上で確立されます。コネクションは接続ファクトリーによって作成されます。

送信ピアは、メッセージを送信するためにプロデューサーを作成します。プロデューサーには、リモートピアでターゲットキューまたはトピックを識別する 宛先 があります。受信ピアは、メッセージを受信するためにコンシューマーを作成します。プロデューサーと同様に、コンシューマーにはリモートピアでソースキューまたはトピックを識別する宛先があります。

宛先は、キューまたはトピックのいずれかです。JMS では、キューとトピックはメッセージを保持する名前付きブローカーエンティティーのクライアント側表現です。

キューは、ポイントツーポイントセマンティクスを実装します。各メッセージは 1 つのコンシューマーによってのみ認識され、メッセージは読み取り後にキューから削除されます。トピックはパブリッシュ/サブスクライブセマンティクスを実装します。各メッセージは複数のコンシューマーによって認識され、メッセージは読み取り後も他のコンシューマーが利用できます。

詳細は「JMS tutorial」を参照してください。

sudo コマンド

本書では、root 権限を必要とするコマンドには sudo が使用されています。何らかの変更がシステム全体に影響する可能性があるため、sudo を使用する場合は注意が必要です。sudo の詳細は、「sudo コマンドの使用」を参照してください。

ファイルパス

本書では、すべてのファイルパスが Linux、UNIX、および同様のオペレーティングシステムで有効です (例: /home/andrea)。Microsoft Windows では、同等の Windows パスを使用する必要があります (例: C:\Users\andrea)。

変数テキスト

本書には、実際の環境に固有の値に置き換える必要がある変数を含むコードブロックが含まれています。変数テキストは中括弧で囲まれ、斜体の等幅フォントとしてスタイル設定されます。たとえば、以下の例では、<project-dir> を実際の環境の値に置き換えます。

$ cd <project-dir>

Red Hat Maven リポジトリーからクライアントライブラリーをダウンロードするように Maven 環境を設定します。

これで、クライアントが Maven プロジェクトで利用できるようになりました。

オンラインリポジトリーの代わりに、ファイルベースの Maven リポジトリーとして AMQ JMS をローカルファイルシステムにインストールできます。

作成されるローカルディレクトリーは、本書全体で <source-dir> と呼ばれます。

Hello World の例では、ブローカーへの接続を作成し、グリーティングが含まれるメッセージを queue キューに送信し、それを受け取ります。成功すると、受け取ったメッセージをコンソールに出力します。

たとえば、Linux で実行すると、以下のような出力になります。

$ java -cp "target/classes/:target/dependency/*" org.apache.qpid.jms.example.HelloWorld
Hello world!

この例のソースコードは <source-dir>/qpid-jms-examples/src/main/java ディレクトリーにあります。JNDI およびロギング設定は <source-dir>/qpid-jms-examples/src/main/resources ディレクトリーにあります。

JMS アプリケーションは、InitialContextFactory から取得した JNDI InitialContext オブジェクトを使用して、接続ファクトリーなどの JMS オブジェクトを検索します。AMQ JMS は、org.apache.qpid.jms.jndi.JmsInitialContextFactory クラスで InitialContextFactory の実装を提供します。

InitialContext オブジェクトがインスタンス化されると、InitialContextFactory の実装が検出されます。

javax.naming.Context context = new javax.naming.InitialContext();

実装を見つけるには、お使いの環境で JNDI を設定する必要があります。これを行う方法は、jndi.properties ファイルの使用、システムプロパティーの使用、または初期コンテキスト API の使用の 3 つの方法があります。

jndi.properties ファイルの使用

jndi.properties という名前のファイルを作成し、Java クラスパスに配置します。java.naming.factory.initial キーでプロパティーを追加します。

java.naming.factory.initial = org.apache.qpid.jms.jndi.JmsInitialContextFactory

Maven ベースのプロジェクトでは、jndi.properties ファイルは <project-dir>/src/main/resources ディレクトリーに配置されます。

システムプロパティーの使用

java.naming.factory.initial システムプロパティーの設定

$ java -Djava.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory ...

初期コンテキスト API の使用

JNDI 初期コンテキスト API を使用してプロパティーをプログラム的に設定します。

Hashtable<Object, Object> env = new Hashtable<>();

env.put("java.naming.factory.initial", "org.apache.qpid.jms.jndi.JmsInitialContextFactory");

InitialContext context = new InitialContext(env);

同じ API を使用して、接続ファクトリー、キュー、およびトピックの JNDI プロパティーを設定できることに注意してください。

JMS 接続ファクトリーは、接続を作成するためのエントリーポイントです。これは、アプリケーション固有の設定をエンコードする接続 URI を使用します。

ファクトリー名と接続 URI を設定するには、以下の形式でプロパティーを作成します。この設定を jndi.properties ファイルに保存するか、対応するシステムプロパティーを設定できます。

connectionFactory.<lookup-name> = <connection-uri>

たとえば、app1 という名前のファクトリーを以下のように設定します。

connectionFactory.app1 = amqp://example.net:5672?jms.clientID=backend

その後、JNDI コンテキストを使用して、app1 という名前を使い、設定済みの接続ファクトリーを検索できます。

ConnectionFactory factory = (ConnectionFactory) context.lookup("app1");

コネクションは接続 URI を使用して設定されます。接続 URI は、クエリーパラメーターとして設定されるリモートホスト、ポート、および設定オプションのセットを指定します。利用可能なオプションについての詳細は、5章SSL 設定オプション を参照してください。

<scheme>://<host>:<port>[?<option>=<value>[&<option>=<value>...]]

暗号化されていない接続のスキームは amqp で、SSL/TLS 接続の場合は amqps です。

たとえば、以下はポート 5672 でホスト example.net に接続する接続 URI で、クライアント ID を backend に設定します。

amqp://example.net:5672?jms.clientID=backend

フェイルオーバー URI

フェイルオーバーが設定されると、現在のサーバーへの接続が失われた場合、クライアントは別のサーバーに自動的に再接続できます。フェイルオーバー URI には接頭辞 failover: があり、括弧内には接続 URI のコンマ区切りリストが含まれます。追加のオプションは最後に指定されます。

failover:(<connection-uri>[,<connection-uri>...])[?<option>=<value>[&<option>=<value>...]]

たとえば、以下は、2 つのホスト (host1 または host2) のいずれかに接続できるフェイルオーバー URI です。

failover:(amqp://host1:5672,amqp://host2:5672)?jms.clientID=backend

接続 URI の例と同様に、クライアントはフェイルオーバー設定で URI を使用して多数の異なる設定で設定できます。これらの設定は、5章SSL 設定オプション で詳しく説明しています。「フェイルオーバーオプション」 セクションも参照してください。

SSL/TLS サーバー名の表示

amqps スキームを使用して SSL/TLS 接続を指定する場合、URI からのホストセグメントは JVM の TLS Server Name Indication (SNI) 拡張によって使用でき、TLS ハンドシェイク時に必要なサーバーのホスト名を通信できます。SNI 拡張は、完全修飾ドメイン名 (例: "myhost.mydomain") が指定されている場合に自動的に含まれますが、修飾されていない名前 (「myhost」など) やベア IP アドレスが使用される場合は定義されません。

JMS は、JNDI を使用してデプロイメント固有のキューとトピックリソースを検索するオプションを提供します。

JNDI でキューおよびトピック名を設定するには、以下の形式でプロパティーを作成します。この設定を jndi.properties ファイルに置くか、対応するシステムプロパティーを設定します。

queue.<lookup-name> = <queue-name>
topic.<lookup-name> = <topic-name>

たとえば、以下のプロパティーは、2 つのデプロイメント固有のリソースに jobs および notifications という名前を定義します。

queue.jobs = app1/work-items
topic.notifications = app1/updates

その後、JNDI 名でリソースを検索できます。

Queue queue = (Queue) context.lookup("jobs");
Topic topic = (Topic) context.lookup("notifications");

JNDI プロパティー値には、${<variable-name>} 形式の変数を含めることができます。ライブラリーは、以下の場所の順序を検索して、変数値を解決します。

たとえば、Linux ${HOME} では、現在のユーザーのホームディレクトリーである HOME 環境変数に解決されます。

構文 ${<variable-name>:-<default-value>} を使用してデフォルト値を指定できます。<variable-name> の値が見つからない場合は、代わりにデフォルト値が使用されます。

これらのオプションは、Connection、Session、MessageConsumer、MessageProducer などの JMS オブジェクトの動作を制御します。

prefetch ポリシーオプション

prefetch ポリシーは、各 MessageConsumer がリモートピアから取得し、ローカルの「prefetch」バッファーに保持されるメッセージ数を決定します。

prefetch の値は、キューまたは共有サブスクリプションの複数のコンシューマーへのメッセージの分散に影響します。値が大きいと、各コンシューマーに一度に送信されるバッチが大きくなる可能性があります。より均等にラウンドロビンの分散を実現するには、小さい値を使用します。

再配信ポリシーオプション

再配信ポリシーは、クライアント上で再配信されたメッセージの処理方法を制御します。

メッセージ ID ポリシーオプション

メッセージ ID ポリシーは、クライアントから送信されたメッセージに割り当てられたメッセージ ID のデータタイプを制御します。

Presettle ポリシーオプション

Presettle ポリシーは、AMQP の事前設定されたメッセージングセマンティクスを使用するように設定されているプロデューサーまたはコンシューマーインスタンスが設定されたタイミングを制御します。

デシリアライズポリシーオプション

デシリアライズポリシーは、シリアル化された Java Object コンテンツで構成される受信 ObjectMessage からボディーを取得しつつ、どの Java タイプがオブジェクトストリームからデシリアライズされるかを制御する手段を提供します。デフォルトでは、本文のデシリアライズの試行時にすべてのタイプが信頼されます。デフォルトのデシリアライズポリシーは、ホワイトリストと Java クラスまたはパッケージ名のブラックリストを指定できるようにする URI オプションを提供します。

プレーン TCP を使用してリモートサーバーに接続する場合、以下のオプションは基礎となるソケットの動作を指定します。これらのオプションは、他の設定オプションと共に接続 URI に追加されます。

amqp://localhost:5672?jms.clientID=foo&transport.connectTimeout=30000

TCP トランスポートオプションの完全なセットを以下に示します。

SSL/TLS トランスポートは、amqps URI スキームを使用して有効にします。SSL/TLS トランスポートは TCP ベースのトランスポートの機能を拡張するため、すべての TCP トランスポートオプションは SSL/TLS トランスポート URI で有効です。

amqps://myhost.mydomain:5671

以下は、SSL/TLS トランスポートオプションの完全なセットです。

以下のオプションは、AMQP ワイヤプロトコルに関連する動作の要素に適用されます。

フェイルオーバー URI は接頭辞 failover: で始まり、括弧内に接続 URI のコンマ区切りリストが含まれます。追加のオプションは最後に指定されます。jms. で始まるオプションは、括弧外にある全体的なフェイルオーバー URI に適用され、その有効期間の Connection オブジェクトに影響します。

failover:(amqp://host1:5672,amqp://host2:5672)?jms.clientID=foo&failover.maxReconnectAttempts=20

括弧内の個別のブローカー詳細は、以前に定義した transport. または amqp. オプションを使用できます。各ホストが接続されていると、これらが適用されます。

failover:(amqp://host1:5672?amqp.option=value,amqp://host2:5672?transport.option=value)?jms.clientID=foo

フェイルオーバーのすべての設定オプションは以下のとおりです。

フェイルオーバー URI は、AMQP およびトランスポートオプションをすべてネスト化されたブローカー URI に指定する手段として、入れ子オプションの定義もサポートします。これは、非フェイルオーバーブローカー URI が前述されているのと同じ transport. および amqp. の URI オプションを使用して実行されますが、failover.nested. のプレフィックスが付けられます。たとえば、接続されたすべてのブローカーに amqp.vhost オプションに同じ値を適用するには、以下のような URI が含まれる場合があります。

failover:(amqp://host1:5672,amqp://host2:5672)?jms.clientID=foo&failover.nested.amqp.vhost=myhost

クライアントにはオプションの検出モジュールがあります。これは、接続するブローカー URI が初期 URI で指定されず、検出エージェントと対話して検出されるカスタムフェールオーバーを提供します。現在、ディスカバリーエージェントの実装には、ファイルから URI をロードするファイル監視と、クライアントをリッスンするブローカーアドレスをブロードキャストするよう設定された ActiveMQ 5.x ブローカーと動作するマルチキャストリスナーとされています。

検出を使用する際のフェイルオーバー関連のオプションの一般的なセットは前述のものと同じで、主な接頭辞は failover. から discovery. に変更され、検出されたすべてのブローカー URI に共通する URI オプションを指定するために nested 接頭辞が使用されます。たとえば、エージェントの URI の詳細がないと、一般的な検出 URI は以下のようになります。

discovery:(<agent-uri>)?discovery.maxReconnectAttempts=20&discovery.discovered.jms.clientID=foo

ファイルウォッチャー検出エージェントを使用するには、以下のようなエージェント URI を作成します。

discovery:(file:///path/to/monitored-file?updateInterval=60000)

ファイルウォッチャーの検出エージェントの URI オプションを以下に示します。

ActiveMQ 5.x ブローカーでマルチキャストディスカバリーエージェントを使用するには、以下のようなエージェント URI を作成します。

discovery:(multicast://default?group=default)

上記のマルチキャストエージェント URI のホストに default を使用することは、エージェントがデフォルトの 239.255.2.3:6155 に置き換える特別な値であることに注意してください。これを変更して、マルチキャスト設定で使用している実際の IP アドレスとポートを指定できます。

マルチキャスト検出エージェントの URI オプションを以下に示します。

通常、JMS を使用するアプリケーションは JNDI を使用してアプリケーションが使用する ConnectionFactory および Destination オブジェクトを取得します。これにより、設定がプログラムから分離され、特定のクライアント実装から分離されます。

これらの例を使用する場合は、以前に詳細に説明したように JNDI コンテキストを設定するために、jndi.properties という名前のファイルをクラスパスに配置する必要があります。

jndi.properties ファイルの内容は、以下に示す内容と一致している必要があります。これにより、クライアントの InitialContextFactory 実装を使用し、ローカルサーバーに接続するための ConnectionFactory を設定し、queue という名前の宛先キューを定義します。

# Configure the InitialContextFactory class to use
java.naming.factory.initial = org.apache.qpid.jms.jndi.JmsInitialContextFactory

# Configure the ConnectionFactory
connectionfactory.myFactoryLookup = amqp://localhost:5672

# Configure the destination
queue.myDestinationLookup = queue

この例では、まず JNDI Context を作成します。これを使用して、ConnectionFactory および Destination を検索するために使用されます。ファクトリーを使用して Connection を作成してから、Session を作成します。次に、MessageProducer が Destination に作成され、メッセージを使用して送信されます。その後、Connection が閉じられ、プログラムは終了します。

この Sender 例の実行可能なバリアントは、以前に3章スタートガイドで説明した例の Hello World とともに、<source-dir>/qpid-jms-examples ディレクトリーにあります。

package org.jboss.amq.example;

import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.DeliveryMode;
import javax.jms.Destination;
import javax.jms.ExceptionListener;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageProducer;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.naming.Context;
import javax.naming.InitialContext;

public class Sender {
  public static void main(String[] args) throws Exception {
    try {
      Context context = new InitialContext(); 1

      ConnectionFactory factory = (ConnectionFactory) context.lookup("myFactoryLookup");
      Destination destination = (Destination) context.lookup("myDestinationLookup"); 2

      Connection connection = factory.createConnection("<username>", "<password>");
      connection.setExceptionListener(new MyExceptionListener());
      connection.start(); 3

      Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 4

      MessageProducer messageProducer = session.createProducer(destination); 5

      TextMessage message = session.createTextMessage("Message Text!"); 6
      messageProducer.send(message, DeliveryMode.NON_PERSISTENT,
                           Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE); 7

      connection.close(); 8
    } catch (Exception exp) {
      System.out.println("Caught exception, exiting.");
      exp.printStackTrace(System.out);
      System.exit(1);
    }
  }

  private static class MyExceptionListener implements ExceptionListener {
    @Override
    public void onException(JMSException exception) {
      System.out.println("Connection ExceptionListener fired, exiting.");
      exception.printStackTrace(System.out);
      System.exit(1);
    }
  }
}

これは単なる例であることに注意してください。実際のアプリケーションは、通常、有効期間の長い MessageProducer を使用し、時間の経過を使用して多数のメッセージを送信します。通常、メッセージごとに Connection、Session、および MessageProducer を開くことは効率的ではありません。

この例では、JNDI コンテキストを作成し、そのコンテキストを使用して ConnectionFactory および Destination を検索し、ファクトリーを使用して Connection を起動してから Session を作成します。次に、Destination に対して MessageConsumer が作成され、それを使用してメッセージを受信し、その内容をコンソールに出力します。その後、接続が閉じられ、プログラムを終了します。送信例 と同じ JNDI 設定が使用されます。

この Receiver 例の実行可能なバリアントは、以前 3章スタートガイド で説明した Hello World 例とともに、クライアントディストリビューションの例ディレクトリー内に含まれています。

package org.jboss.amq.example;

import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.Destination;
import javax.jms.ExceptionListener;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageConsumer;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.naming.Context;
import javax.naming.InitialContext;

public class Receiver {
  public static void main(String[] args) throws Exception {
    try {
      Context context = new InitialContext(); 1

      ConnectionFactory factory = (ConnectionFactory) context.lookup("myFactoryLookup");
      Destination destination = (Destination) context.lookup("myDestinationLookup"); 2

      Connection connection = factory.createConnection("<username>", "<password>");
      connection.setExceptionListener(new MyExceptionListener());
      connection.start(); 3

      Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 4

      MessageConsumer messageConsumer = session.createConsumer(destination); 5

      Message message = messageConsumer.receive(5000); 6

      if (message == null) { 7
        System.out.println("A message was not received within given time.");
      } else {
        System.out.println("Received message: " + ((TextMessage) message).getText());
      }

      connection.close(); 8
    } catch (Exception exp) {
      System.out.println("Caught exception, exiting.");
      exp.printStackTrace(System.out);
      System.exit(1);
    }
 }

  private static class MyExceptionListener implements ExceptionListener {
    @Override
    public void onException(JMSException exception) {
      System.out.println("Connection ExceptionListener fired, exiting.");
      exception.printStackTrace(System.out);
      System.exit(1);
    }
  }
}

これは単なる例であることに注意してください。実際のアプリケーションは、通常有効期限の長い MessageConsumer を使用し、時間の経過とともに多数のメッセージを受信します。通常、各メッセージに対して Connection、Session、および MessageConsumer を開くことは効率的ではありません。

SSL/TLS 接続は、パフォーマンスを改善するためにネイティブの OpenSSL 実装を使用するように設定できます。OpenSSL を使用するには、transport.useOpenSSL オプションが有効にされ、OpenSSL サポートライブラリーがクラスパスで利用可能でなければなりません。

Red Hat Enterprise Linux でインストールされた OpenSSL ライブラリーを使用するには、openssl および apr RPM パッケージをインストールし、以下の依存関係を POM ファイルに追加します。

<dependency>
  <groupId>io.netty</groupId>
  <artifactId>netty-tcnative</artifactId>
  <version>2.0.39.Final-redhat-00001</version>
  <classifier>linux-x86_64-fedora</classifier>
</dependency>

OpenSSL ライブラリーの実装のリストは、Netty プロジェクトから入手できます。

クライアントは、適切に設定されたサーバーで使用される場合に Kerberos を使用して認証するように設定できます。Kerberos を有効にするには、以下の手順に従います。

使用される正確な設定は、接続のためにクレデンシャルを確立する方法と、使用中の特定の LoginModule によって異なります。Oracle Krb5LoginModule の詳細は、「Oracle Krb5LoginModule class reference」を参照してください。IBM Java 8 Krb5LoginModule の詳細は、IBM Krb5LoginModule class reference を参照してください。

プリンシパルの指定や既存のチケットキャッシュまたはキータブを使用するかどうかなど、Kerberos プロセスに使用する認証情報を確立するように LoginModule を設定できます。ただし、LoginModule 設定が、必要なすべての認証情報を確立する手段を提供しない場合は、これを要求して、クライアント Connection オブジェクトからユーザー名とパスワードの値が渡されます。これは、ConnectionFactory を使用するか、URI オプションから以前に設定した Connection を作成するときに、これらの値が提供される場合です。

Kerberos は認証の目的でのみサポートされることに注意してください。暗号化には SSL/TLS 接続を使用します。

以下の接続 URI オプションを使用して Kerberos 認証プロセスに影響を与えることができます。

これまでで説明する amqp. および transport. オプションと同様に、これらのオプションはホストごとに、またはフェイルオーバー URI のすべてのホストネストされたオプションに指定する必要があります。

メッセージングシステムは、メッセージ確認を使用して、メッセージの送信ゴールが頻繁に行われるかどうかを追跡します。

メッセージが送信されると、メッセージが送信されてから、確認応答するまでの期間が発生します (メッセージは「in flight (進行中)」です)。その間ネットワーク接続が失われた場合、メッセージ配信のステータスは不明となり、配信が完了するまで、アプリケーションコードで特別な処理が必要になる場合があります。

以下のセクションでは、接続に失敗した場合にメッセージ配信の条件を示します。

未承認の配信とトランザクション以外のプロデューサー

メッセージが進行中の場合、送信タイムアウトが設定されておらず、経過していないとすると、再接続後に再度送信されます。

ユーザーのアクションは不要です。

トランザクションがコミットされていないトランザクションとのトランザクションプロデューサー

メッセージが進行中の場合は、再接続後に再度送信されます。新しいトランザクションで送信が最初に送信された場合は、再接続後に通常通りに送信が続行されます。トランザクションに 1 つ前の送信がある場合は、トランザクションが失敗したと見なされ、後続のコミット操作によって TransactionRolledBackException がスローされます。

配信を図るには、失敗したトランザクションに属するメッセージを再送信する必要があります。

保留中のコミットとトランザクションプロデューサー

コミットが フライト である場合、トランザクションは失敗とみなされ、後続のコミット操作によって TransactionRolledBackException がスローされます。

配信を図るには、失敗したトランザクションに属するメッセージを再送信する必要があります。

未承認配信のあるトランザクションでないコンシューマー

メッセージが受信してもまだ確認されていないと、メッセージを承認すると、エラーは生成されませんが、クライアントによるアクションはありません。

受信したメッセージが確認されていないため、プロデューサーは再送することがあります。重複を回避するために、ユーザーはメッセージ ID で重複メッセージをフィルタリングする必要があります。

コミットされていないトランザクションを使用したトランザクションコンシューマー

アクティブなトランザクションがまだコミットされていない場合は、失敗とみなされ、保留中の承認はドロップされます。後続のコミット操作によって TransactionRolledBackException がスローされます。

プロデューサーは、トランザクションに属するメッセージを再送信する可能性があります。重複を回避するために、ユーザーはメッセージ ID で重複メッセージをフィルタリングする必要があります。

保留中のコミットのあるトランザクションコンシューマー

コミットがフライトの場合、トランザクションは失敗とみなされます。後続のコミット操作によって TransactionRolledBackException がスローされます。

プロデューサーは、トランザクションに属するメッセージを再送信する可能性があります。重複を回避するために、ユーザーはメッセージ ID で重複メッセージをフィルタリングする必要があります。

クライアントは、JMS 仕様で定義されたもの以外の追加のセッション確認モードをサポートします。

個別確認応答

このモードでは、セッションが CLIENT_ACKNOWLEDGE モードの場合に使用される Message.acknowledge() メソッドを使用して、メッセージを個別に承認する必要があります。CLIENT_ACKNOWLEDGE モードとは異なり、ターゲットメッセージのみが確認されます。それ以外の配信されたメッセージはすべて承認されていないままになります。このモードを有効にするために使用される整数値は 101 です。

connection.createSession(false, 101);

確認なし

このモードでは、クライアントへのディスパッチ前にサーバーでメッセージを受け入れ、承認はクライアントによって実行されません。クライアントは、このモードをアクティブにするために 2 つの整数値をサポートします (100 および 257)。

connection.createSession(false, 100);

クライアントは SLF4J API を使用し、ユーザーがニーズに基づいて特定のロギング実装を選択できるようにします。たとえば、ユーザーは slf4j-log4j バインディングを提供して Log4J 実装を選択できます。SLF4J の詳細は、その Web サイト から入手できます。

クライアントは org.apache.qpid.jms 階層内に存在する Logger の名前を使用します。これを使用して、ニーズに合わせてロギング実装を設定することができます。

デバッグ時には、Qpid Proton AMQP 1.0 ライブラリーから追加のプロトコルトレースロギングを有効にすると便利です。これを行う方法は 2 つあります。

入力および出力バイトの低レベルトレースを出力するようにクライアントを設定することもできます。これを有効にするには、オプション transport.traceBytes=true を接続 URI に追加し、org.apache.qpid.jms.transports.netty.NettyTcpTransport ロガーをログレベル DEBUG に設定します。

アプリケーションでトレースを有効にするには、以下の手順に従います。

アプリケーションをキャプチャーするトレースを表示するには、Jaeger Getting Started を使用して Jaeger インフラストラクチャーおよびコンソールを実行します。

AMQP メッセージは AMQP タイプシステムを使用して構成されます。この一般的な形式を使用するのは、異なる言語の AMQP クライアントが、相互運用できることが理由です。このセクションでは、クライアントと他の AMQP クライアントの使用を支援するために、使用されるさまざまな JMS メッセージタイプに関連して、クライアントによって送受信された AMQP ペイロードに関する動作を文書化します。

AMQ Broker は AMQP 1.0 クライアントと相互運用するために設計されています。以下をチェックして、ブローカーが AMQP メッセージング用に設定されていることを確認します。

AMQ Interconnect は AMQP 1.0 クライアントと動作します。以下をチェックして、コンポーネントが正しく設定されていることを確認します。