AMQ JMS는 업계에서 인정하는 다음 표준 및 네트워크 프로토콜을 지원합니다.

AMQ JMS 지원 구성에 대한 최신 정보는 Red Hat Customer Portal에서 Red Hat AMQ 지원 구성을 참조하십시오.

이 섹션에서는 핵심 API 엔티티를 소개하고 함께 작동하는 방법을 설명합니다.

AMQ JMS는 메시지를 보내고 수신합니다. 메시지 생산자와 소비자를 사용하여 연결된 피어 간에 메시지가 전송됩니다. 생산자와 소비자는 세션에 따라 설정됩니다. 세션은 연결을 통해 설정됩니다. 연결은 연결 팩토리에 의해 생성됩니다.

전송 피어는 메시지를 보낼 생산자를 생성합니다. 생산자에는 원격 피어에서 대상 큐 또는 주제를 식별하는 대상이 있습니다. 수신하는 피어는 메시지를 수신할 소비자를 생성합니다. 생산자와 마찬가지로 소비자에는 원격 피어에서 소스 큐 또는 주제를 식별하는 대상이 있습니다.

대상은 큐 또는 주제입니다. JMS에서 큐와 주제는 메시지를 보유하는 이름이 지정된 브로커 엔티티의 클라이언트 측 표현입니다.

큐는 지점 간 의미 체계를 구현합니다.A queue implements point-to-point semantics. 각 메시지는 한 명의 소비자가 볼 수 있으며 메시지를 읽은 후 큐에서 제거됩니다. 주제는 게시-서브스크립션 의미 체계를 구현합니다. 각 메시지는 여러 소비자가 볼 수 있으며 메시지를 읽은 후에는 다른 소비자가 계속 사용할 수 있습니다.

자세한 내용은 JMS 튜토리얼을 참조하십시오.

sudo 명령

이 문서에서 sudo 는 root 권한이 필요한 모든 명령에 사용됩니다. 변경 사항이 전체 시스템에 영향을 줄 수 있으므로 sudo 를 사용할 때는 주의하십시오. sudo 에 대한 자세한 내용은 sudo 명령 사용을 참조하십시오.

파일 경로

이 문서에서 모든 파일 경로는 Linux, UNIX 및 유사한 운영 체제(예: /home/andrea)에 유효합니다. Microsoft Windows에서는 동등한 Windows 경로(예: C:\Users\andrea)를 사용해야 합니다.

변수 텍스트

이 문서에는 환경과 관련된 값으로 교체해야 하는 변수가 있는 코드 블록이 포함되어 있습니다. 변수 텍스트는 화살표 중괄호로 묶고 italic monospace로 스타일링됩니다. 예를 들어 다음 명령에서 < project-dir> 을 사용자 환경의 값으로 바꿉니다.

$ cd <project-dir>

Red Hat Maven 리포지토리에서 클라이언트 라이브러리를 다운로드하도록 Maven 환경을 구성합니다.

이제 Maven 프로젝트에서 클라이언트를 사용할 수 있습니다.

온라인 리포지토리 대신 AMQ JMS를 파일 기반 Maven 리포지토리로 로컬 파일 시스템에 설치할 수 있습니다.

결과 로컬 디렉터리를 이 문서 전체에서 &lt ;source-dir&gt;이라고 합니다.

Hello World 예제에서는 브로커에 대한 연결을 생성하고 큐 큐에 인사말을 포함하는 메시지를 전송한 다음 다시 수신합니다. 성공하면 수신된 메시지를 콘솔에 출력합니다.

예를 들어 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 애플리케이션은 InitialContext Factory 에서 얻은 JNDI InitialContext 오브젝트를 사용하여 연결 팩토리와 같은 JMS 개체를 조회합니다. AMQ JMS는 org.apache.qpid.jms.jndi.Jms InitialContextFactory 클래스에서 InitialContextFactory 구현을 제공합니다.

InitialContextFactory 구현은 InitialContext 오브젝트가 인스턴스화될 때 검색됩니다.

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

구현을 찾으려면 사용자 환경에서 JNDI를 구성해야 합니다. 이 작업을 수행하는 방법은 jndi.properties 파일 사용, 시스템 속성 사용 또는 초기 컨텍스트 API 사용의 세 가지입니다.

jndi.properties 파일 사용

jndi.properties 라는 파일을 생성하여 Java classpath에 배치합니다. 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장. 구성 옵션 을 참조하십시오.

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

스키마는 암호화되지 않은 연결에 대한 amqp 이며 SSL/TLS 연결을 위한 amqps 입니다.

예를 들어 다음은 포트 5672 에서 host example.net 에 연결하고 클라이언트 ID를 backend 로 설정하는 연결 URI입니다.

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

장애 조치 URI

장애 조치가 구성되면 현재 서버에 대한 연결이 끊어지면 클라이언트가 다른 서버에 자동으로 다시 연결할 수 있습니다. 장애 조치(failover) URI에는 장애 조치( failover): 가 있으며 Geneve 내에 쉼표로 구분된 연결 URI 목록을 포함합니다. 추가 옵션은 끝에 지정됩니다.

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

예를 들어 다음은 두 호스트 host1 또는 host2 중 하나에 연결할 수 있는 장애 조치 URI입니다.

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

연결 URI 예제와 마찬가지로 장애 조치 구성의 URI를 사용하여 다양한 설정으로 클라이언트를 구성할 수 있습니다. 이러한 설정은 5장. 구성 옵션 에 자세히 설명되어 있으며 5.5절. “장애 조치 옵션” 섹션은 특히 중요합니다.

SSL/TLS 서버 이름 표시

amqps 스키마가 SSL/TLS 연결을 지정하는 데 사용되는 경우 URI의 호스트 세그먼트는 JVM의 TLS 서버 이름 표시(SNI) 확장에서 사용하여 TLS 핸드셰이크 중에 원하는 서버 호스트 이름을 전달할 수 있습니다. 정규화된 도메인 이름(예: "myhost.mydomain")이 지정되었지만 정규화되지 않은 이름(예: "myhost") 또는 베어 IP 주소가 사용되는 경우 SNI 확장이 자동으로 포함됩니다.

JMS는 JNDI를 사용하여 배포별 큐 및 주제 리소스를 찾는 옵션을 제공합니다.

JNDI에서 큐 및 주제 이름을 설정하려면 다음 형식으로 속성을 생성합니다. 이 구성을 jndi.properties 파일에 배치하거나 해당 시스템 속성을 설정합니다.

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

예를 들어 다음 속성은 두 가지 배포별 리소스에 대한 이름 작업 및 알림을 정의합니다.

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&gt;에 대한 값이 없으면 기본값이 대신 사용됩니다.

이러한 옵션은 연결,세션,MessageConsumer 및 MessageProducer 와 같은 JMS 개체의 동작을 제어합니다.

사전 가져오기 정책 옵션

사전 페치 정책은 각 MessageConsumer 가 원격 피어에서 가져와서 로컬 "사전 패치" 버퍼에 보관하는 메시지 수를 결정합니다.

prefetch 값은 큐 또는 공유 구독에서 여러 사용자에게 메시지 배포에 영향을 줄 수 있습니다. 값이 클수록 더 큰 배치가 각 소비자에게 전송될 수 있습니다. 더 많은 라운드 로빈 배포를 수행하려면 더 낮은 값을 사용합니다.

Redelivery 정책 옵션

Redelivery policy는 클라이언트에서 재전송된 메시지를 처리하는 방법을 제어합니다.

메시지 ID 정책 옵션

메시지 ID 정책은 클라이언트에서 보낸 메시지에 할당된 메시지 ID의 데이터 유형을 제어합니다.

Presettle 정책 옵션

Presettle 정책은 AMQP 사전 설정 메시징 의미 체계를 사용하도록 생산자 또는 소비자 인스턴스가 구성된 시기를 제어합니다.

deserialization 정책 옵션

deserialization 정책은 직렬화된 Java Object 콘텐츠로 구성된 들어오는 ObjectMessage 에서 본문을 검색하는 동안 개체 스트림에서 역직렬화할 수 있는 Java 유형을 제어하는 수단을 제공합니다. 기본적으로 모든 형식은 본문의 역직렬화 시도 중에 신뢰할 수 있습니다.By default, all types are trusted during an attempt to deserialize the body. 기본 직렬화 정책은 허용 목록 및 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 유선 프로토콜과 관련된 동작 측면에 적용됩니다.

장애 조치(failover) URI는 접두사 페일오버: 로 시작하고, Geneve 내에 쉼표로 구분된 연결 URI 목록을 포함합니다. 추가 옵션은 끝에 지정됩니다. jms 로 접두사가 지정된 옵션은 괄호 외부에 전체 장애 조치 URI에 적용되며 수명 동안 Connection 오브젝트에 영향을 미칩니다.

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

ScanSetting 내의 개별 브로커 세부 정보는 전송 또는 이전에 정의한 amqp. 옵션을 사용할 수 있습니다. 각 호스트가 연결된 대로 적용됩니다.

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

장애 조치에 대한 모든 구성 옵션은 아래에 나열되어 있습니다.

또한 장애 조치 URI는 개별 중첩된 브로커 URI에 적용되는 AMQP 및 전송 옵션 값을 지정하는 수단으로 중첩된 옵션 정의도 지원합니다. 이는 동일한 전송 과 amqp를 사용하여 수행됩니다. 장애 조치(failover) 브로커 URI가 아닌 경우 URI 옵션은 이전에 설명되었지만 failover.nested 접두사가 붙습니다.. 예를 들어 amqp.vhost 옵션에 동일한 값을 적용하려면 연결된 모든 브로커에 다음과 같은 URI가 있을 수 있습니다.

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

클라이언트에는 연결할 브로커 URI가 초기 URI에 제공되지 않고 검색 에이전트와 상호 작용하여 검색 URI가 표시되는 사용자 지정 장애 조치 계층을 제공하는 선택적 검색 모듈이 있습니다. 현재 두 개의 검색 에이전트 구현이 있습니다. 파일에서 URI를 로드하는 파일 조사기 및 수신 대기 클라이언트를 위해 브로커 주소를 브로드캐스트하도록 구성된 ActiveMQ 5.x 브로커와 함께 작동하는 멀티 캐스트 리스너입니다.

discovery를 사용할 때 일반적인 장애 조치 관련 옵션 세트는 기본 접두사가 failover. 에서 discovery 로 변경되었으며 검색된 모든 브로커 URI에 공통 URI 옵션을 제공하는 데 사용되는 중첩된 접두사와 동일합니다. 예를 들어 에이전트 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 라는 파일을 classpath에 배치해야 합니다.

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 컨텍스트 를 생성하고 이를 사용하여 ConnectionFactory 및 Destination 을 조회하고, 팩토리를 사용하여 연결을 생성 및 시작한 다음 세션을 생성합니다. 그런 다음 MessageProducer 이 대상에 생성되고 메시지를 사용하여 전송됩니다. 그러면 연결이 닫히고 프로그램이 종료됩니다.

이 Sender 예제의 실행 가능한 변형은 < source-dir>/qpid-jms-examples 디렉터리에 있으며 이전에 3장. 시작하기 에서 다루는 Hello World 예제에 있습니다.

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를 사용하고 시간이 지남에 따라 많은 메시지를 사용합니다. 일반적으로 메시지당 연결,세션, MessageProducer 를 여는 것은 효율적이지 않습니다.

이 예제는 JNDI 컨텍스트를 생성하고, 이를 사용하여 ConnectionFactory 및 Destination 을 찾고, 팩토리를 사용하여 연결을 생성 및 시작한 다음 세션을 생성합니다. 그런 다음 대상에 대해 MessageConsumer 가 생성되고 이를 사용하여 메시지를 수신하며 해당 콘텐츠가 콘솔에 출력됩니다. 그러면 연결이 닫히고 프로그램이 종료됩니다. 전송 예에서 와 동일한 JNDI 구성이 사용됩니다.

이 수신기 예제의 실행 가능한 변형은 이전에 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 를 사용하고 시간이 지남에 따라 많은 메시지를 수신합니다. 각 메시지에 대한 연결,세션 및 MessageConsumer 를 열고 종료하는 것은 일반적으로 효율적이지 않습니다.

성능 향상을 위해 기본 OpenSSL 구현을 사용하도록 SSL/TLS 연결을 구성할 수 있습니다. OpenSSL을 사용하려면 transport.useOpenSSL 옵션을 활성화해야 하며 classpath에서 OpenSSL 지원 라이브러리를 사용할 수 있어야 합니다.

Red Hat Enterprise Linux에서 시스템에서 설치한 OpenSSL 라이브러리를 사용하려면 openssl 및 apr RPM 패키지를 설치하고 POM 파일에 다음 종속성을 추가합니다.

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

OpenSSL 라이브러리 구현 목록은 Netty 프로젝트에서 사용할 수 있습니다.

적절하게 구성된 서버와 함께 사용할 때 Kerberos를 사용하여 인증하도록 클라이언트를 구성할 수 있습니다. Kerberos를 활성화하려면 다음 단계를 사용합니다.

사용되는 정확한 구성은 연결에 사용할 인증 정보를 설정하는 방법과 사용 중인 특정 LoginModule 에 따라 달라집니다. Oracle Krb5LoginModule 에 대한 자세한 내용은 Oracle Krb5LoginModule 클래스 참조를 참조하십시오. IBM Java 8 Krb5LoginModule 에 대한 자세한 내용은 IBM Krb5LoginModule 클래스 참조를 참조하십시오.

보안 주체 지정 및 기존 티켓 캐시 또는 keytab 사용 여부 등 Kerberos 프로세스에 사용할 자격 증명을 설정하도록 LoginModule 을 구성할 수 있습니다. 그러나 LoginModule 구성이 필요한 모든 자격 증명을 설정하는 수단을 제공하지 않으면 ConnectionFactory 를 사용하거나 URI 옵션을 통해 이전에 구성된 연결을 생성할 때 클라이언트 연결 오브젝트에서 사용자 이름 및 암호 값을 요청하고 전달할 수 있습니다.

Kerberos는 인증 목적으로만 지원됩니다. 암호화에 SSL/TLS 연결을 사용합니다.

다음 연결 URI 옵션을 사용하여 Kerberos 인증 프로세스에 영향을 줄 수 있습니다.

amqp. 및 transport와 유사합니다. 이전에 설명된 옵션은 호스트별로 또는 장애 조치 URI의 모든 호스트 중첩 옵션으로 지정해야 합니다.

메시징 시스템은 메시지 승인을 사용하여 메시지 전송의 목적을 실제로 달성했는지를 추적합니다.

메시지가 전송되면 메시지가 전송된 후 및 승인되기 전 까지의 시간이 있습니다(메시지는 "전달 중"). 해당 시간 동안 네트워크 연결이 손실되면 메시지 전달 상태를 알 수 없으며 완료를 보장하기 위해 애플리케이션 코드에서 전송에 특별한 처리가 필요할 수 있습니다.

아래 섹션에서는 연결이 실패할 때 메시지 전달 조건을 설명합니다.

승인되지 않은 생산자와 함께 번역되지 않은 생산자

메시지가 이동 중이면 다시 연결한 후 전송 시간 초과가 설정되지 않고 경과되지 않은 경우 다시 전송됩니다.

사용자 작업이 필요하지 않습니다.

커밋되지 않은 트랜잭션이 있는 트랜잭션 생성

메시지가 이동 중이면 다시 연결한 후 전송됩니다. 새 트랜잭션의 첫 번째 전송인 경우 다시 연결한 후 전송이 정상적으로 계속됩니다. 이전에 트랜잭션에서 전송하는 경우 트랜잭션이 실패한 것으로 간주되고 후속 커밋 작업에서 TransactionRolledBackException 이 발생합니다.

전송을 위해 사용자는 실패한 트랜잭션에 속하는 메시지를 다시 보내야 합니다.

보류 중인 커밋을 사용하여 생산자를 트랜잭션

커밋이 해제되면 트랜잭션이 실패한 것으로 간주되고 후속 커밋 작업에서 TransactionRolledBackException 이 발생합니다.

전송을 위해 사용자는 실패한 트랜잭션에 속하는 메시지를 다시 보내야 합니다.

승인되지 않은 배송을 통해 번역되지 않은 소비자

메시지가 수신되었지만 아직 승인되지 않은 경우 메시지를 확인하면 오류가 발생하지 않지만 클라이언트가 작업을 수행하지 않습니다.

수신된 메시지가 승인되지 않기 때문에 생산자가 다시 보낼 수 있습니다. 중복을 방지하려면 사용자가 메시지 ID로 중복 메시지를 필터링해야 합니다.

커밋되지 않은 트랜잭션이 있는 트랜잭션

활성 트랜잭션이 아직 커밋되지 않은 경우 실패한 것으로 간주되고 보류 중인 승인이 삭제됩니다. 후속 커밋 작업은 TransactionRolledBackException 을 throw합니다.

생산자는 트랜잭션에 속하는 메시지를 다시 보낼 수 있습니다. 중복을 방지하려면 사용자가 메시지 ID로 중복 메시지를 필터링해야 합니다.

보류 중인 커밋으로 소비자를 트랜잭션

커밋이 진행 중이면 트랜잭션이 실패한 것으로 간주됩니다. 후속 커밋 작업은 TransactionRolledBackException 을 throw합니다.

생산자는 트랜잭션에 속하는 메시지를 다시 보낼 수 있습니다. 중복을 방지하려면 사용자가 메시지 ID로 중복 메시지를 필터링해야 합니다.

클라이언트는 JMS 사양에 정의된 두 가지 추가 세션 승인 모드를 지원합니다.

개별 승인

이 모드에서 세션이 CLIENT_ACKNOWLEDGE 모드에 있을 때 사용되는 Message.acknowledge() 메서드를 사용하여 애플리케이션에서 메시지를 개별적으로 승인해야 합니다. CLIENT_ACKNOWLEDGE 모드와 달리 대상 메시지만 승인됩니다. 다른 모든 전송 메시지는 승인되지 않은 상태로 유지됩니다. 이 모드를 활성화하는 데 사용되는 정수 값은 101입니다.

connection.createSession(false, 101);

승인 없음

이 모드에서는 클라이언트에 디스패치되기 전에 서버에서 메시지가 수락되고 클라이언트에서 승인을 수행하지 않습니다. 클라이언트는 이 모드를 활성화하기 위해 두 개의 정수 값, 100 및 257을 지원합니다.

connection.createSession(false, 100);

클라이언트는 SLF4J API를 사용하여 사용자가 필요에 따라 특정 로깅 구현을 선택할 수 있습니다. 예를 들어, 사용자는 slf4j-log4j 바인딩을 제공하여 Log4J 구현을 선택할 수 있습니다. SLF4J에 대한 자세한 내용은 웹 사이트에서 확인할 수 있습니다.

클라이언트는 org.apache.qpid.jms 계층 구조에 있는 Logger 이름을 사용하여 필요에 따라 로깅 구현을 구성할 수 있습니다.

디버깅할 때 Cryostat Proton AMQP 1.0 라이브러리에서 추가 프로토콜 추적 로깅을 활성화하는 것이 유용한 경우가 있습니다. 이를 수행하는 방법은 다음 두 가지가 있습니다.

입력 및 출력 바이트의 하위 수준 추적을 내보내도록 클라이언트를 구성할 수도 있습니다. 이를 활성화하려면 연결 URI 에 transport.traceBytes=true 옵션을 추가하고 org.apache.qpid.jms.transports.netty.NettyTcpTransport 로거를 로그 수준 DEBUG 로 구성합니다.

다음 단계를 사용하여 애플리케이션에서 추적을 활성화합니다.

애플리케이션 캡처 추적을 보려면 Jaeger 시작하기 를 사용하여 Jaeger 인프라 및 콘솔을 실행합니다.

AMQP 메시지는 AMQP 유형 시스템을 사용하여 구성됩니다. 이러한 공통 형식을 갖는 것은 다른 언어의 AMQP 클라이언트가 서로 상호 운용할 수 있는 이유 중 하나입니다. 이 섹션은 다른 AMQP 클라이언트와 함께 클라이언트 사용을 지원하기 위해 사용되는 다양한 JMS Message 유형과 관련하여 클라이언트에서 전송 및 수신한 AMQP 페이로드 관련 동작을 문서화하는 역할을 합니다.

AMQ Broker는 AMQP 1.0 클라이언트와 상호 작동하도록 설계되었습니다. 브로커가 AMQP 메시징에 대해 구성되었는지 확인하려면 다음을 확인하십시오.