AMQ Core Protocol JMS는 다음과 같은 업계 인식 표준 및 네트워크 프로토콜을 지원합니다.

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

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

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

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

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

큐는 지점 간 의미 체계를 구현합니다. 각 메시지는 하나의 소비자가 볼 수 있으며 메시지는 읽기 후 큐에서 제거됩니다. 주제에서는 게시-서브스크립션 의미 체계를 구현합니다. 각 메시지는 여러 소비자가 볼 수 있으며, 메시지는 읽기 후에 다른 소비자가 사용할 수 있습니다.

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

sudo 명령

이 문서에서는 root 권한이 필요한 모든 명령에 sudo 를 사용합니다. 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 Core Protocol JMS를 파일 기반 Maven 리포지토리로 로컬 파일 시스템에 설치할 수 있습니다.

이 예제에서는 exampleQueue 라는 큐에 대한 소비자 및 생산자를 생성합니다. 텍스트 메시지를 전송한 다음 이를 다시 수신하여 수신된 메시지를 콘솔에 인쇄합니다.

예를 들어 Linux에서 실행하면 다음과 같은 출력이 생성됩니다.

$ java -cp "target/classes:target/dependency/*" org.apache.activemq.artemis.jms.example.QueueExample
Sent message: This is a text message
Received message: This is a text message

예제의 소스 코드는 < install-dir> /examples/features/standard/queue/src 디렉터리에 있습니다. 추가 예제는 < install-dir> /examples/features/standard 디렉토리에서 사용할 수 있습니다.

JMS 애플리케이션은 InitialContext Factory 에서 얻은 JNDI InitialContext 오브젝트를 사용하여 연결 팩토리와 같은 JMS 개체를 찾습니다. AMQ Core Protocol JMS는 org.apache.activemq.artemis.jndi.ActiveMQ 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.activemq.artemis.jndi.ActiveMQInitialContextFactory

Maven 기반 프로젝트에서 jndi.properties 파일은 < project-dir> /src/main/resources 디렉터리에 배치됩니다.

시스템 속성 사용

java.naming.factory.initial 시스템 속성을 설정합니다.

$ java -Djava.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory ...

초기 컨텍스트 API 사용

JNDI 초기 컨텍스트 API 를 사용하여 속성을 프로그래밍 방식으로 설정합니다.

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

env.put("java.naming.factory.initial", "org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory");

InitialContext context = new InitialContext(env);

동일한 API를 사용하여 연결 팩토리, 큐 및 항목에 대한 JNDI 속성을 설정할 수 있습니다.

JMS 연결 팩토리는 연결을 생성하기 위한 진입점입니다. 애플리케이션별 구성 설정을 인코딩하는 연결 URI를 사용합니다.

팩토리 이름 및 연결 URI를 설정하려면 아래 형식으로 속성을 생성합니다. 이 구성을 jndi.properties 파일에 저장하거나 해당 시스템 속성을 설정할 수 있습니다.

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

예를 들어 app1 이라는 팩토리를 구성하는 방법은 다음과 같습니다.

connectionFactory.app1 = tcp://example.net:61616?clientID=backend

그러면 JNDI 컨텍스트를 사용하여 app1 이라는 이름으로 구성된 연결 팩토리를 조회할 수 있습니다.

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

연결은 연결 URI를 사용하여 구성됩니다. 연결 URI는 원격 호스트, 포트 및 쿼리 매개변수로 설정된 구성 옵션 집합을 지정합니다. 사용 가능한 옵션에 대한 자세한 내용은 5장. 구성 옵션 을 참조하십시오.

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

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

tcp://example.net:61616?clientID=backend

tcp 외에도 AMQ Core Protocol JMS는 vm,udp, jgroups 체계도 지원합니다. 이는 대체 전송을 나타내며 브로커에 해당 어셉터 구성이 있습니다.

장애 조치 URI

URI에는 여러 대상 연결 URI가 포함될 수 있습니다. 하나의 대상에 대한 초기 연결이 실패하면 다른 대상을 시도합니다. 다음과 같은 형식을 취합니다.

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

세차 외부의 옵션은 모든 연결 URI에 적용됩니다.

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");

자세한 내용은 8장. 흐름 제어의 내용을 참조하십시오.

클라이언트는 minLargeMessageSize 속성의 값을 설정하여 큰 메시지 지원을 활성화할 수 있습니다. minLargeMessageSize 보다 큰 메시지는 큰 메시지로 간주됩니다.

클라이언트는 모든 마스터 및 슬레이브 브로커에 대한 정보를 수신할 수 있으므로 연결 실패 시 슬레이브 브로커에 다시 연결할 수 있습니다. 그런 다음 슬레이브 브로커는 장애 조치 전에 각 연결에 존재하는 모든 세션과 소비자를 자동으로 다시 생성합니다. 이 기능을 사용하면 애플리케이션에서 수동 다시 연결 논리를 직접 코딩할 필요가 없습니다.

슬레이브에서 세션이 다시 생성되면 이미 전송되거나 승인된 메시지에 대한 지식이 없습니다. 장애 조치 시 진행 중인 모든 전송 또는 승인이 손실될 수 있습니다. 그러나 투명한 장애 조치(Failover)가 없어도 중복 탐지 및 트랜잭션 재시도의 조합을 사용하여 오류 발생 시에도 한 번만 제공하는 것을 한 번만 보장할 수 있습니다.

클라이언트는 구성 가능한 기간 내에 브로커에서 패킷을 수신하지 못한 경우 연결 오류를 탐지합니다. 자세한 내용은 6.3절. “손상된 연결 감지”를 참조하십시오.

마스터 및 슬레이브에 대한 정보를 수신하도록 클라이언트를 구성하는 여러 방법이 있습니다. 한 가지 옵션은 특정 브로커에 연결하도록 클라이언트를 구성한 다음 클러스터의 다른 브로커에 대한 정보를 수신하는 것입니다. 자세한 내용은 6.7절. “정적 검색 구성”를 참조하십시오. 그러나 가장 일반적인 방법은 브로커 검색을 사용하는 것입니다. 브로커 검색을 구성하는 방법에 대한 자세한 내용은 6.6절. “동적 검색 구성” 을 참조하십시오.

또한 아래 예제와 같이 브로커에 연결하는 데 사용되는 URI의 쿼리 문자열에 매개변수를 추가하여 클라이언트를 구성할 수 있습니다.

connectionFactory.ConnectionFactory=tcp://localhost:61616?ha=true&reconnectAttempts=3

ConnectionFactory cf =  ActiveMQJMSClient.createConnectionFactory(...)
cf.setInitialConnectAttempts(3);

<configuration>
 <core>
  ...
  <initial-connect-attempts>3</initial-connect-attempts> 1
  ...
 </core>
</configuration>

경우에 따라 자동 클라이언트 장애 조치를 원하지 않지만 대신 실패 처리기에서 자체 재연결 논리를 코딩하는 것을 선호합니다. 이는 애플리케이션 수준에서 장애 조치(failover)가 처리되므로 애플리케이션 수준 장애 조치라고 합니다.This is known as application-level failover, since the failover is handled at the application level.

JMS를 사용할 때 애플리케이션 수준 장애 조치를 구현하려면 JMS 연결에서 ExceptionListener 클래스를 설정합니다. ExceptionListener 는 연결 오류가 감지되는 경우 브로커에 의해 호출됩니다. ExceptionListener 에서 이전 JMS 연결을 종료해야 합니다. JNDI에서 새 연결 팩토리 인스턴스를 조회하고 새 연결을 생성할 수도 있습니다.

브로커로부터 데이터를 수신하는 한 클라이언트는 연결을 활성으로 간주합니다. client-failure-check-period 속성에 대한 값을 제공하여 클라이언트가 실패 연결을 확인하도록 구성합니다. 네트워크 연결의 기본 검사 기간은 10.0.0.1밀리초 또는 30초이며, VM 내 연결에 대한 기본값은 -1이며, 이는 데이터가 수신되지 않은 경우 클라이언트가 해당 측에서 연결을 실패하지 않습니다.

일반적으로 점검 기간을 브로커의 연결 시간-라이브에 사용된 값보다 훨씬 낮게 설정하여 일시적인 오류가 발생할 경우 클라이언트가 다시 연결할 수 있도록 합니다.

손실된 연결 감지에 대한 검사 기간 설정

아래 예제에서는 확인 기간을 10,000밀리초로 설정하는 방법을 보여줍니다.

기본적으로 클라이언트는 자체 연결에 대해 TTL(Time-to-Live)을 설정할 수 있습니다. 아래 예제에서는 TTL을 설정하는 방법을 보여줍니다.

클라이언트 애플리케이션이 종료된 연결이 발생하지 않도록 종료하기 전에 리소스를 제어하는 방식으로 닫아야 합니다. Java에서는 finally 블록 내에서 연결을 닫는 것이 좋습니다.

Connection jmsConnection = null;
try {
   ConnectionFactory jmsConnectionFactory = ActiveMQJMSClient.createConnectionFactoryWithoutHA(...);
   jmsConnection = jmsConnectionFactory.createConnection();
   ...use the connection...
}
finally {
   if (jmsConnection != null) {
      jmsConnection.close();
   }
}

연결을 설정할 때 브로커 목록을 검색하도록 AMQ Core Protocol JMS를 구성할 수 있습니다.

클라이언트에서 JNDI를 사용하여 JMS 연결 팩토리 인스턴스를 조회하는 경우 JNDI 컨텍스트 환경에서 이러한 매개변수를 지정할 수 있습니다. 일반적으로 매개변수는 jndi.properties 라는 파일에 정의됩니다. 연결 팩토리에 대한 URI의 호스트와 부분은 broker.xml 구성 파일 내의 해당 broadcast-group 의 group-address 및 group-port 와 일치해야 합니다. 다음은 브로커의 검색 그룹에 연결하도록 구성된 jndi.properties 파일의 예입니다.

java.naming.factory.initial = ActiveMQInitialContextFactory
connectionFactory.myConnectionFactory=udp://231.7.7.7:9876

클라이언트 애플리케이션에 의해 JNDI에서 이 연결 팩토리를 다운로드하고 JMS 연결이 생성되면 해당 연결은 브로커의 검색 그룹 구성에 지정된 멀티 캐스트 주소를 수신하여 검색 그룹이 유지 관리하는 서버 목록에 부하를 분산합니다.

JNDI를 사용하는 대신 JMS 연결 팩토리를 생성할 때 Java 코드에서 직접 검색 그룹 매개 변수를 지정할 수 있습니다. 아래 코드는 이 작업을 수행하는 방법에 대한 예를 보여줍니다.

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

DiscoveryGroupConfiguration discoveryGroupConfiguration = new DiscoveryGroupConfiguration();
UDPBroadcastEndpointFactory udpBroadcastEndpointFactory = new UDPBroadcastEndpointFactory();
udpBroadcastEndpointFactory.setGroupAddress(groupAddress).setGroupPort(groupPort);
discoveryGroupConfiguration.setBroadcastEndpointFactory(udpBroadcastEndpointFactory);

ConnectionFactory jmsConnectionFactory = ActiveMQJMSClient.createConnectionFactoryWithHA
    (discoveryGroupConfiguration, JMSFactoryType.CF);

Connection jmsConnection1 = jmsConnectionFactory.createConnection();
Connection jmsConnection2 = jmsConnectionFactory.createConnection();

setter 메서드 setRefreshTimeout() 을 사용하여 DiscoveryGroupConfiguration 에서 새로 고침 시간 초과를 직접 설정할 수 있습니다. 기본값은 10000밀리초입니다.

첫 번째 사용 시 연결 팩토리에서 첫 번째 연결을 생성하기 전에 생성 이후 이 기간이 대기 중인지 확인합니다. 기본 대기 시간은 10000밀리초이지만 새 값을 DiscoveryGroupConfiguration.setDiscoveryInitialWaitTimeout() 에 전달하여 변경할 수 있습니다.

사용 중인 네트워크에서 UDP를 사용하는 것이 불가능할 수 있습니다. 이 경우 사용 가능한 서버의 초기 목록을 사용하여 연결을 구성할 수 있습니다. 목록은 항상 사용할 수 있는 하나의 브로커 또는 하나 이상의 사용 가능한 브로커 목록일 수 있습니다.

이는 모든 서버가 호스팅되는 위치를 알아야 한다는 의미는 아닙니다. 신뢰할 수 있는 서버를 사용하여 에 연결하도록 이러한 서버를 구성할 수 있습니다. 연결 정보가 연결되면 연결 세부 정보가 서버에서 클라이언트로 전파됩니다.

클라이언트에서 JNDI를 사용하여 JMS 연결 팩토리 인스턴스를 조회하는 경우 JNDI 컨텍스트 환경에서 이러한 매개변수를 지정할 수 있습니다. 일반적으로 매개변수는 jndi.properties 라는 파일에 정의됩니다. 다음은 동적 검색을 사용하는 대신 브로커의 정적 목록을 제공하는 jndi.properties 파일의 예입니다.

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connectionFactory.myConnectionFactory=(tcp://myhost:61616,tcp://myhost2:61616)

위의 연결 팩토리를 클라이언트가 사용하는 경우 해당 연결은차단 () 내에 정의된 브로커 목록에 걸쳐 부하 분산됩니다.

JMS 연결 팩토리를 직접 인스턴스화하는 경우 아래 예제와 같이 JMS 연결 팩토리를 생성할 때 커넥터 목록을 명시적으로 지정할 수 있습니다.

HashMap<String, Object> map = new HashMap<String, Object>();
map.put("host", "myhost");
map.put("port", "61616");
TransportConfiguration broker1 = new TransportConfiguration
    (NettyConnectorFactory.class.getName(), map);

HashMap<String, Object> map2 = new HashMap<String, Object>();
map2.put("host", "myhost2");
map2.put("port", "61617");
TransportConfiguration broker2 = new TransportConfiguration
    (NettyConnectorFactory.class.getName(), map2);

ActiveMQConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithHA
    (JMSFactoryType.CF, broker1, broker2);

커넥터는 클라이언트가 브로커에 연결하는 방법을 정의합니다. JMS 연결 팩토리를 사용하여 클라이언트에서 구성할 수 있습니다.

Map<String, Object> connectionParams = new HashMap<String, Object>();

connectionParams.put(org.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants.PORT_PROP_NAME, 61617);

TransportConfiguration transportConfiguration =
    new TransportConfiguration(
    "org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory", connectionParams);

ConnectionFactory connectionFactory = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);

Connection jmsConnection = connectionFactory.createConnection();

큰 메시지에 작성하려면 10.0.0.1s Message.writeBytes() 메서드를 사용합니다. 다음 예제에서는 파일에서 바이트를 읽고 메시지에 씁니다.

BytesMessage message = session.createBytesMessage();
File inputFile = new File(inputFilePath);
InputStream inputStream = new FileInputStream(inputFile);

int numRead;
byte[] buffer = new byte[1024];

while ((numRead = inputStream.read(buffer, 0, buffer.length)) != -1) {
    message.writeBytes(buffer, 0, numRead);
}

큰 메시지에서 읽으려면 10.0.0.1s Message.readBytes() 메서드를 사용합니다. 다음 예제에서는 메시지에서 바이트를 읽고 파일에 씁니다.

BytesMessage message = (BytesMessage) consumer.receive();
File outputFile = new File(outputFilePath);
OutputStream outputStream = new FileOutputStream(outputFile);

int numRead;
byte buffer[] = new byte[1024];

for (int pos = 0; pos < message.getBodyLength(); pos += buffer.length) {
    numRead = message.readBytes(buffer);
    outputStream.write(buffer, 0, numRead);
}

메시지 그룹은 다음과 같은 특징이 있는 메시지 집합입니다.

메시지 그룹은 속성의 특정 값에 대한 모든 메시지를 동일한 소비자가 직렬로 처리하려는 경우 유용합니다. 예를 들어 특정 스포일 구매에 대한 주문이 동일한 소비자에 의해 순차적으로 처리되도록 할 수 있습니다. 이렇게 하려면 소비자 풀을 만든 다음 스톡 이름을 메시지 속성 값으로 설정할 수 있습니다.To do this, you could create a pool of consumers and then set the shares as the value of the message property. 이렇게 하면 특정 제품의 모든 메시지가 항상 동일한 소비자가 처리합니다.

그룹 ID 설정

아래 예제에서는 AMQ Core Protocol JMS와 함께 메시지 그룹을 사용하는 방법을 보여줍니다.

추가 리소스

메시지 그룹 구성 및 사용 방법에 대한 작업 예제는 < install-dir> /examples/features/standard 아래의 message-group 및 message-group2 를 참조하십시오.

AMQ Broker에는 수신한 중복 메시지를 필터링하여 자체 중복 탐지 논리를 코딩할 필요가 없는 자동 중복 메시지 탐지가 포함되어 있습니다.

중복 메시지 탐지를 활성화하려면 메시지 속성 _AMQ_DUPL_ID 에 고유한 값을 입력합니다. 브로커가 메시지를 수신하면 _AMQ_DUPL_ID 에 값이 있는지 확인합니다. 이 경우 브로커는 메모리 캐시에서 확인하여 해당 값이 이미 메시지를 수신했는지 확인합니다. 동일한 값을 가진 메시지가 발견되면 들어오는 메시지가 무시됩니다.

트랜잭션에서 메시지를 보내는 경우 트랜잭션의 모든 메시지에 대해 _AMQ_DUPL_ID 를 설정하지 않아도 됩니다. 브로커가 트랜잭션의 모든 메시지에 대해 중복 메시지를 감지하면 전체 트랜잭션을 무시합니다.

중복 ID 메시지 속성 설정

다음 예제에서는 AMQ Core Protocol JMS를 사용하여 중복 탐지 속성을 설정하는 방법을 보여줍니다. 편의를 위해 클라이언트는 중복 ID 속성 이름인 _ AMQ_DUPLECTION_ID에 대해 org.apache.activemq.artemis.api.Message.HDR_DUPLICATE_DETECTION _ID 값을 사용합니다.

Message jmsMessage = session.createMessage();
String myUniqueID = "This is my unique id";
message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID);

AMQ Core Protocol JMS를 사용하면 클라이언트를 입력 또는 종료하는 패킷을 인터셉트할 수 있으므로 패킷을 감사하거나 메시지를 필터링할 수 있습니다. 인터셉터는 가로채는 패킷을 변경할 수 있습니다. 그러면 인터셉터가 강력하지만 주의해서 사용해야 하는 기능이기도 합니다.

인터셉터는 부울 값을 반환하는 intercept() 메서드를 구현해야 합니다. 반환된 값이 true 이면 메시지 패킷은 계속됩니다. 반환된 값이 false 이면 프로세스가 중단되고 다른 인터셉터가 호출되지 않으며 메시지 패킷은 더 이상 처리되지 않습니다.

발신 패킷이 전송 모드로 전송되는 경우를 제외하고 메시지 가로채기(Message interception)는 주 클라이언트 코드에 투명하게 수행됩니다. 차단을 활성화하여 나가는 패킷이 전송되고 해당 패킷이 false 를 반환하는 인터셉터가 발생하면 ActiveMQException이 호출자에게 발생합니다. throw된 예외에는 인터셉터의 이름이 포함됩니다.

인터셉터는 org.apache.artemis.activemq.api.core.Interceptor 인터페이스를 구현해야 합니다. 클라이언트 인터셉터 클래스와 해당 종속 항목을 올바르게 인스턴스화하고 호출하려면 클라이언트의 Java 클래스 경로에 추가해야 합니다.

package com.example;

import org.apache.artemis.activemq.api.core.Interceptor;
import org.apache.activemq.artemis.core.protocol.core.Packet;
import org.apache.activemq.artemis.spi.core.protocol.RemotingConnection;

public class MyInterceptor implements Interceptor {
    private final int ACCEPTABLE_SIZE = 1024;

    @Override
    boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException {
        int size = packet.getPacketSize();
        if (size <= ACCEPTABLE_SIZE) {
            System.out.println("This Packet has an acceptable size.");
            return true;
        }
        return false;
    }
}

클라이언트 쪽 버퍼에 보관된 최대 메시지 크기는 창 크기에 따라 결정됩니다. AMQ Core Protocol JMS의 기본 창 크기는 1MiB 또는 1024 * 1024바이트입니다. 대부분의 사용 사례에서 기본값은 정상입니다. 다른 경우 창 크기의 최적 값을 찾으려면 시스템 벤치마킹이 필요할 수 있습니다. default를 변경해야 하는 경우 AMQ Core Protocol JMS를 사용하면 버퍼 창 크기를 설정할 수 있습니다.

다음 예제에서는 AMQ Core Protocol JMS를 사용할 때 소비자 창 크기 매개 변수를 설정하는 방법을 보여줍니다. 각 예제에서는 소비자 창 크기를 300,000바이트로 설정합니다.

창 크기는 창의 각 바이트에 대해 한 번의 크립션을 기반으로 브로커와 프로듀서 간에 협상됩니다. 메시지가 전송되고 프로젝션이 사용되는 경우, 생산자는 더 많은 메시지를 보내기 전에 프로듀서가 요청되고 브로커의 교집합을 부여해야합니다. 생산자와 브로커 간의 교집합을 교환하면 생산자와 브로커 간의 데이터 흐름이 규제됩니다.

다음 예제에서는 AMQ Core Protocol JMS를 사용할 때 생산자 창 크기를 1024바이트로 설정하는 방법을 보여줍니다.

빠른 소비자는 메시지를 사용하는 만큼 빠르게 처리할 수 있습니다. 메시징 시스템의 소비자가 해당 속도가 빠르면 창 크기를 -1로 설정하는 것이 좋습니다. 창 크기를 이 값으로 설정하면 클라이언트에서 바인딩되지 않은 메시지가 버퍼링됩니다. 그러나 이 설정은 신중하게 사용합니다. 소비자가 메시지를 수신하는 즉시 메시지를 처리할 수 없는 경우 클라이언트의 메모리가 오버플로될 수 있습니다.

빠른 소비자를 위한 창 크기 설정

아래 예제에서는 메시지의 빠른 소비자인 AMQ Core Protocol JMS 클라이언트를 사용할 때 창 크기를 -1로 설정하는 방법을 보여줍니다.

느린 소비자는 각 메시지를 처리하는 데 상당한 시간이 걸립니다. 이 경우 클라이언트에서 메시지를 버퍼링하지 않는 것이 좋습니다. 메시지는 다른 소비자가 사용할 준비가 된 브로커에 남아 있습니다. 버퍼를 끄는 한 가지 이점은 큐에서 여러 소비자 간에 결정적 분산을 제공한다는 것입니다. 클라이언트 쪽 버퍼를 비활성화하여 느린 소비자를 처리하려면 창 크기를 0으로 설정합니다.

느린 사용자의 창 크기 설정

아래 예제에서는 메시지의 느린 소비자인 AMQ Core Protocol JMS 클라이언트를 사용할 때 창 크기를 0으로 설정하는 방법을 보여줍니다.

추가 리소스

느린 소비자를 처리할 때 소비자 버퍼링을 방지하기 위해 브로커를 구성하는 방법을 보여주는 예제는 예제는 < install-dir> /examples/표준 에서 no-consumer-buffering 예제를 참조하십시오.

소비자가 메시지를 사용할 수 있는 속도를 규제할 수 있습니다. 또한 제한 으로 알려진 소비 속도를 규제하여 소비자가 구성에서 허용하는 것보다 빠른 속도로 메시지를 소비하지 않도록 합니다.

이 기능을 사용하려면 비율이 양수 정수여야 하며 초당 메시지 단위에 지정된 최대 메시지 소비 속도입니다. 속도를 -1로 설정하면 속도 제한 흐름 제어가 비활성화됩니다. 기본값은 -1입니다.

아래 예제에서는 사용 메시지의 속도를 초당 10개의 메시지로 제한하는 클라이언트를 보여줍니다.

추가 리소스

소비자 속도를 제한하는 방법의 작동 예는 < install-dir> /examples/standard 의 consumer-rate-limit 예제를 참조하십시오.

AMQ Core Protocol JMS는 생산자가 메시지를 보내는 속도를 제한할 수도 있습니다. 생산자 비율은 초당 메시지 단위로 지정됩니다. 기본값인 -1로 설정하면 속도가 제한된 흐름 제어가 비활성화됩니다.

아래 예제에서는 생산자가 AMQ Core Protocol JMS를 사용할 때 메시지 전송 속도를 설정하는 방법을 보여줍니다. 각 예제에서는 최대 속도를 초당 10개의 메시지로 설정합니다.

추가 리소스

메시지 전송 속도를 제한하는 방법에 대한 작업 예제는 < install-dir> /examples/standard 의 producer-rate-limit 예제를 참조하십시오.