Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

메시징 구성

Red Hat JBoss Enterprise Application Platform 7.4

Red Hat JBoss Enterprise Application Platform용 메시징 애플리케이션을 개발 및 배포하려는 개발자와 관리자를 위한 지침 및 정보.

Red Hat Customer Content Services

초록

이 문서에서는 Red Hat JBoss Enterprise Application Platform으로 메시징 애플리케이션을 개발 및 배포하려는 개발자와 관리자를 위한 정보를 제공합니다.

JBoss EAP 문서에 대한 피드백 제공
링크 복사

오류를 보고하거나 문서를 개선하기 위해 Red Hat Jira 계정에 로그인하여 문제를 제출하십시오. Red Hat Jira 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.

절차

  1. 티켓을 생성하려면 다음 링크를 클릭하십시오.
  2. 문서 URL, 섹션 번호 를 포함하고 문제를 설명하십시오.
  3. 요약 에 문제에 대한 간략한 설명을 입력합니다.
  4. 설명에서 문제 또는 개선 사항에 대한 자세한 설명을 제공합니다. 문서에서 문제가 발생한 위치에 URL을 포함합니다.
  5. Submit 을 클릭하고 문제를 적절한 문서 팀으로 라우팅합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체
링크 복사

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

I 부. 메시징 및 JBoss EAP 7 정보
링크 복사

JBoss EAP 6의 메시징 브로커는 JBoss 커뮤니티 프로젝트인 HornetQ라고 했습니다. HornetQ 코드베이스는 Apache ActiveMQ 프로젝트에 기증되었으며 HornetQ 커뮤니티는 기증된 코드베이스를 개선하고 차세대 메시징 브로커를 생성하기 위해 해당 프로젝트에 참여했습니다. 그 결과 JBoss EAP 7용 메시징 브로커인 Apache ActiveMQ Artemis가 메시징 통합 및 JBoss EAP 6와의 이전 버전과의 호환성을 제공합니다. ActiveMQ Artemis는 JBoss EAP 6에서 HornetQ 브로커와의 프로토콜 호환성을 유지하는 반면 몇 가지 스마트한 새 기능도 포함합니다. 이 가이드에서는 JBoss EAP 7.4에서 사용할 수 있는 ActiveMQ Artemis 브로커의 많은 기능을 살펴보고 유용한 예를 제공합니다.

1장. 메시징 개념
링크 복사

1.1. 메시징 시스템
링크 복사

메시징 시스템을 사용하면 이기종 시스템을 더 높은 안정성과 함께 느슨하게 결합할 수 있습니다. RPC(원격 프로시저 호출) 패턴을 기반으로 하는 시스템과 달리 메시징 시스템은 주로 요청과 응답 간의 긴밀한 관계 없이 패턴을 전달하는 비동기 메시지를 사용합니다. 대부분의 메시징 시스템은 필요한 경우 요청 응답 모드를 지원할 수 있을 만큼 유연하지만 메시징 시스템의 주요 기능은 아닙니다.

메시징 시스템은 메시지 발신자를 소비자로부터 분리합니다. 사실 메시지의 발신자와 소비자는 완전히 독립적이며 서로를 알지 못합니다. 따라서 유연하고 느슨하게 연결된 시스템을 만들 수 있습니다. 대기업에서는 메시징 시스템을 사용하여 이기종 시스템을 느슨하게 결합하는 메시지 버스를 구현하는 경우가 많습니다. 메시지 버스는 ESB(Enterprise Service Bus)의 핵심을 구성할 수 있습니다. 메시지 버스를 사용하여 분산된 시스템을 분리하면 시스템을 확장하고 더욱 쉽게 조정할 수 있습니다. 또한 새 시스템을 추가하거나 기존 시스템을 폐기할 수 있는 유연성이 향상되어 있으므로 서로에 대해 취약한 종속성이 없기 때문입니다.

또한 메시징 시스템은 전달 보장과 같은 개념을 통합하여 안정적인 메시징, 트랜잭션을 통해 여러 메시지를 단일 작업 단위로 통합하고, 메시지를 서버 오류나 다시 시작해도 메시지를 허용하도록 허용할 수 있습니다.

1.2. 메시징 스타일
링크 복사

대부분의 메시징 시스템에서 지원하는 두 종류의 메시징 스타일은 점대점 패턴과 게시-구독 패턴입니다.

  • 점대점 패턴

    점대점 패턴은 대기열에서 단일 소비자 수신 대기에 메시지를 보내는 작업이 포함됩니다. 대기열에서 한 번 메시지는 일반적으로 전송을 보장하기 위해 지속됩니다. 메시지가 대기열을 통과하면 메시징 시스템은 이를 소비자에게 전달합니다. 소비자는 메시지가 처리되면 메시지 전달을 승인합니다. 동일한 메시지에 대해 동일한 큐에서 수신 대기하는 여러 소비자가 있을 수 있지만 하나의 소비자만 각 메시지를 수신합니다.

  • 게시-서브스크립션 패턴

    게시-서브스크립션 패턴을 사용하면 보낸 사람이 단일 대상을 사용하여 여러 소비자에게 메시지를 보낼 수 있습니다. 이 대상은 종종 주제 라고 합니다. 각 항목에는 여러 소비자 또는 구독자가 있을 수 있으며 점대점 메시징과는 달리 모든 구독자는 토픽에 게시된 모든 메시지를 받습니다.

    또 다른 흥미로운 차이점은 서브스크립션 가입 고객이 지속적일 수 있다는 것입니다. 지속적 서브스크립션은 연결할 때 서버에 고유한 식별자를 전달하므로, 마지막으로 가입자가 연결한 이후 마지막으로 토픽에 게시된 메시지를 확인하고 전송할 수 있습니다. 이러한 메시지는 일반적으로 다시 시작한 후에도 서버에서 유지됩니다.

1.3. 자카르타 메시징
링크 복사

Jakarta Messaging 2.0은 자카르타 메시징 에서 정의됩니다. Jakarta Messaging은 점대점 및 게시-구독자 메시징 스타일 모두를 제공하는 Java API입니다. 자카르타 메시징은 트랜잭션 사용을 통합합니다. Jakarta Messaging은 표준 유선 형식을 정의하지 않으므로 Jakarta Messaging 공급자의 벤더는 모두 표준 API를 사용할 수 있지만 서로 다른 내부 유선 프로토콜을 사용하여 클라이언트와 서버 간에 통신할 수 있습니다.

1.4. 자카르타 메시징 대상
링크 복사

Jakarta Messaging 대상은 자카르타 메시징 연결 팩토리와 함께 관리 개체입니다. 대상은 메시지를 생성하고 사용하는 데 Jakarta Messaging 클라이언트에서 사용합니다. 대상을 사용하면 클라이언트가 메시지를 생성할 때 대상과 메시지를 사용할 때 메시지의 소스를 지정할 수 있습니다. 게시-서브스크립션 패턴을 사용하면 대상을 주제라고 합니다. 점대점 패턴을 사용하면 대상을 큐라고 합니다.

애플리케이션은 서버 측에서 구성되고 일반적으로 JNDI를 통해 액세스하는 다양한 자카르타 메시징 대상을 사용할 수 있습니다.

2장. 통합 ActiveMQ Artemis 메시징 브로커
링크 복사

2.1. ActiveMQ Artemis
링크 복사

Apache ActiveMQ Artemis는 비동기 메시징 시스템의 오픈소스 프로젝트입니다. 고성능, 임베딩 가능, 클러스터형이며 여러 프로토콜을 지원합니다. JBoss EAP 7은 Apache ActiveMQ Artemis를 자카르타 메시징 브로커로 사용하며 messaging-activemq 하위 시스템을 사용하여 구성됩니다. 이는 HornetQ 브로커를 완전히 대체하지만 JBoss EAP 6와 프로토콜 호환성이 유지됩니다.

핵심 ActiveMQ Artemis는 자카르타 메시징과 무관하며 핵심 API라고 하는 비Jakarta Messaging API 를 제공합니다. ActiveMQ Artemis는 또한 facade 계층을 사용하여 핵심 API 위에 Jakarta Messaging 의미 체계를 구현하는 Jakarta Messaging 클라이언트 API를 제공합니다. 기본적으로 Jakarta Messaging 상호 작용은 자카르타 메시징 클라이언트 API를 사용하여 클라이언트 측의 핵심 API 작업으로 변환됩니다. 여기에서 핵심 클라이언트 API 및 Apache ActiveMQ Artemis 유선 형식을 사용하여 모든 작업이 전송됩니다. 서버 자체는 코어 API만 사용합니다. 핵심 API 및 해당 개념에 대한 자세한 내용은 ActiveMQ Artemis 설명서를 참조하십시오.

2.2. Apache ActiveMQ Artemis 코어 API 및 Jakarta Messaging 대상
링크 복사

Jakarta Messaging 대상이 Apache ActiveMQ Artemis 주소에 매핑되는 방법을 빠르게 논의합니다.

Apache ActiveMQ Artemis 코어는 자카르타 메시징과 무관합니다. 자카르타 메시징 주제의 개념이 없습니다. Jakarta Messaging 주제는 0개 이상의 큐가 바인딩된 주소(주제 이름)로 핵심으로 구현됩니다. 해당 주소에 바인딩된 각 대기열은 토픽 서브스크립션을 나타냅니다. 마찬가지로 자카르타 메시징 큐는 자카르타 메시징 큐를 나타내는 하나의 대기열이 바인딩된 주소(Norizor Messaging 대기열 이름)로 구현됩니다.

관례적으로 모든 Jakarta Messaging 대기열은 코어 큐 이름에 jms.queue. 앞에 문자열이 있는 코어 큐에 매핑됩니다. 예를 들어, orders.europe라는 이름의 자카르타 메시징 큐는 jms. queue.orders.europe 라는 코어 대기열에 매핑됩니다. 코어 큐가 바인딩된 주소는 코어 큐 이름으로도 제공됩니다.

Jakarta Messaging 주제의 경우 서브스크립션을 나타내는 큐가 자카르타 메시징 주제의 이름에 jms.topic. 앞에 추가하여 제공되는 주소입니다. 예를 들어 이름이 news.europe인 Jakarta Messaging 주제는 jms. topic.news.europe 의 핵심 주소에 매핑됩니다.

즉, 이름을 주문한 자카르타 메시징 큐에 Jakarta Messaging 메시지를 보내는 경우 서버에서 주소 jms.queue.orders.europe 에 바인딩된 모든 코어 큐로 라우팅됩니다. news.europe라는 이름의 자카르타 메시징 주제로 자카르타 메시징 메시지를 보내면 서버에서 주소 jms. topic.news.europe 에 바인딩된 코어 대기열로 라우팅됩니다.

사용자 이름 orders.europe 를 사용하여 Jakarta Messaging 큐의 설정을 구성하려면 해당 코어 대기열 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>
Copy to Clipboard Toggle word wrap

II 부. Single-Node 메시징 시스템 구성
링크 복사

파트 II는 helloworld-mdb 빠른 시작을 사용하여 JBoss EAP 7 메시징을 시작하는 가이드로 시작합니다. 설치에 사용할 수 있는 구성 옵션은 보안 및 지속성과 같은 주제를 포함합니다. 클러스터링, 고가용성 및 다른 서버 연결과 같은 주제를 포함하여 JBoss EAP 7의 여러 설치와 관련된 구성은 Part III, Multi-Node Messaging Systems 구성을 참조하십시오.

3장. 시작하기
링크 복사

3.1. helloworld-mdb 빠른 시작 사용
링크 복사

helloworld-mdb 빠른 시작에서는 간단한 메시지 기반 빈을 사용하여 기본적인 Jakarta EE 메시징 기능을 보여줍니다. 기본 구성을 검토할 때 빠른 시작과 실행이 이루어지면 JBoss EAP 메시징 서버에 포함된 기능을 소개할 수 있습니다.

helloworld-mdb 빠른 시작 빌드 및 배포

helloworld-mdb 빠른 시작 빌드 및 배포에 대한 지침은 빠른 시작과 함께 제공되는 README.md 파일의 지침을 참조하십시오. messaging-activemq 하위 시스템이 포함된 전체 구성을 지정하는 JBoss EAP 서버를 시작해야 합니다. 다른 구성 파일로 JBoss EAP를 시작하는 방법에 대한 자세한 내용은 README.md 파일 또는 JBoss EAP 구성 가이드를 참조하십시오.

3.2. 메시징 하위 시스템 구성 개요
링크 복사

messaging-activemq 하위 시스템에 대한 기본 구성은 full 또는 full -ha 구성으로 JBoss EAP 서버를 시작할 때 포함됩니다. full-ha 옵션에는 클러스터링 및 고가용성과 같은 기능을 위한 고급 구성이 포함되어 있습니다.

필요하지 않지만, 이 구성 개요와 함께 실행하려면 helloworld-mdb 빠른 시작을 작업 예제로 사용하는 것이 좋습니다.

messaging-activemq 하위 시스템에서 사용할 수 있는 모든 설정에 대한 자세한 내용은 EAP_HOME/docs/schema/ 디렉터리에 있는 스키마 정의를 참조하거나 다음과 같이 관리 CLI의 하위 시스템에서 read-resource-description 작업을 실행합니다. 

/subsystem=messaging-activemq:read-resource-description(recursive=true)
Copy to Clipboard Toggle word wrap

서버 구성 파일의 다음 확장 기능은 JBoss EAP에 messaging-activemq 하위 시스템을 런타임의 일부로 포함하도록 지시합니다. 

<extensions>
  ...
  <extension module="org.wildfly.extension.messaging-activemq"/>
  ...
</extensions>
Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap
연결 정보

메시징 클라이언트는 자카르타 메시징 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"/>
Copy to Clipboard Toggle word wrap

자세한 내용은 연결 팩트 구성 섹션을 참조하십시오.

커넥터 및 수락자

각 자카르타 메시징 연결 팩토리는 커넥터를 사용하여 클라이언트 생산자 또는 소비자에서 메시징 서버로의 자카르타 메시징 지원 통신을 활성화합니다. 커넥터 오브젝트는 메시징 서버에 연결하는 데 사용하는 전송 및 매개 변수를 정의합니다. 이에 대응하는 어셉터 개체는 메시징 서버에서 수락한 연결 유형을 식별합니다.

기본 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"/>
Copy to Clipboard Toggle word wrap

예제: 기본 Acceptors

<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>
Copy to Clipboard Toggle word wrap

자세한 내용은 Acceptors 및 Connectors 섹션을 참조하십시오.

소켓 바인딩 그룹

기본 커넥터의 socket-binding 특성은 http 라는 소켓 바인딩을 참조합니다. JBoss EAP는 표준 웹 포트를 통해 인바운드 요청을 멀티플렉싱할 수 있기 때문에 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>
Copy to Clipboard Toggle word wrap

소켓 바인딩에 대한 자세한 내용은 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>
Copy to Clipboard Toggle word wrap

이는 와일드카드 # 에 명시된 대로 역할 게스트 가 있는 모든 사용자가 서버의 모든 주소에 액세스할 수 있음을 선언합니다. 와일드카드 구문에 대한 자세한 내용은 주소 설정 구성을 참조하십시오.

대상 및 원격 연결 보안에 대한 자세한 내용은 메시징 보안 구성을 참조하십시오.

메시징 대상

전체 및 full-ha 구성에는 JBoss EAP가 만료되었거나 적절한 대상으로 라우팅할 수 없는 두 개의 유용한 대기열이 포함됩니다. 

<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
Copy to Clipboard Toggle word wrap

다음 방법 중 하나를 사용하여 JBoss EAP에 고유한 메시징 대상을 추가할 수 있습니다.

  • 관리 CLI 사용

    다음 관리 CLI 명령을 사용하여 큐를 추가합니다. 

    jms-queue add --queue-address=testQueue  --entries=queue/test,java:jboss/exported/jms/queue/test
    Copy to Clipboard Toggle word wrap

    다음 관리 CLI 명령을 사용하여 주제를 추가합니다. 

    jms-topic add --topic-address=testTopic  --entries=topic/test,java:jboss/exported/jms/topic/test
    Copy to Clipboard Toggle word wrap

  • 관리 콘솔 사용

    메시징 대상은 Configuration → Subsystems → Messaging (ActiveMQ) → Server 로 이동한 후 서버를 선택하고, 대상을 선택하고, 보기를 클릭하여 관리 콘솔에서 구성할 수 있습니다. JMS Queue 탭을 선택하여 대기열을 구성하고 JMS 토픽을 선택하여 토픽 을 구성합니다.

  • Jakarta EE 배포 설명자 또는 주석을 사용하여 대상 정의.

    Jakarta EE 8에서는 배포 설명자에 큐 및 토픽 구성이 포함될 수 있습니다. 다음은 자카르타 메시징 큐를 정의하는 자카르타 EE 설명자 파일의 코드 조각입니다. 

    ...
<jms-destination>
   <name>java:global/jms/MyQueue</name>
   <interfaceName>javax.jms.Queue</interfaceName>
   <destinationName>myQueue</destinationName>
</jms-destination>
...
    Copy to Clipboard Toggle word wrap

    예를 들어, helloworld-mdb 빠른 시작의 메시지 기반 빈에는 애플리케이션을 실행하는 데 필요한 대기열 및 주제를 정의하는 주석이 포함되어 있습니다. 이 방식으로 생성된 대상은 런타임 대기열 목록에 표시됩니다. 관리 CLI를 사용하여 런타임 대기열 목록을 표시합니다. 빠른 시작을 배포하면 생성된 런타임 큐가 다음과 같이 표시됩니다. 

    /subsystem=messaging-activemq/server=default/runtime-queue=*:read-resource
{
    "outcome" => "success",
    "result" => [
        ...
        {
            "address" => [
                ("subsystem" => "messaging-activemq"),
                ("server" => "default"),
                ("runtime-queue" => "jms.queue.HelloWorldMDBQueue")
            ],
            "outcome" => "success",
            "result" => {"durable" => undefined}
        },
        ...
        {
            "address" => [
                ("subsystem" => "messaging-activemq"),
                ("server" => "default"),
                ("runtime-queue" => "jms.topic.HelloWorldMDBTopic")
            ],
            "outcome" => "success",
            "result" => {"durable" => undefined}
        },
        ...
    ]
}
    Copy to Clipboard Toggle word wrap

자세한 내용은 Configuring Messaging Destinations 에서 참조하십시오.

4장. 메시징 대상 구성
링크 복사

참고

메시징 대상을 구성하려면 JBoss EAP에 메시징이 활성화되어 있어야 합니다. 이 기능은 standalone -full.xml 또는 standalone-full-ha.xml 구성 파일로 실행할 때 기본적으로 활성화됩니다. domain.xml 구성 파일에는 메시징도 활성화되어 있습니다.

4.1. 큐 추가
링크 복사

Jakarta Messaging 큐를 추가하려면 관리 CLI에서 jms-queue 명령을 사용합니다. 

jms-queue add --queue-address=myQueue --entries=[queue/myQueue jms/queue/myQueue java:jboss/exported/jms/queue/myQueue]
Copy to Clipboard Toggle word wrap

entries 특성은 단일 공백으로 구분된 여러 JNDI 이름을 포함하는 목록입니다. 또한 [] 대괄호를 사용하여 JNDI 이름 목록을 묶을 수도 있습니다. queue-address 는 라우팅 구성을 제공하고, 항목은 클라이언트가 큐를 조회하는 데 사용할 수 있는 JNDI 이름 목록을 제공합니다.

큐의 속성 읽기

관리 CLI에서 jms-queue 명령을 사용하여 큐 구성을 읽을 수 있습니다. 

jms-queue read-resource --queue-address=myQueue
Copy to Clipboard Toggle word wrap

또는 관리 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
    }
}
Copy to Clipboard Toggle word wrap

jms-queue의 특성

관리 CLI는 다음 명령이 제공된 경우 jms-queue 구성 요소의 모든 특성을 표시합니다. 

/subsystem=messaging-activemq/server=default/jms-queue=*:read-resource-description()
Copy to Clipboard Toggle word wrap

아래 표는 jms-queue:

Expand
속성설명

consumer-count

이 큐의 메시지를 사용하는 소비자 수입니다. 런타임 시 이용 가능.

dead-letter-address

배달된 메시지를 보낼 주소입니다. 자세한 내용은 배달 못 한 편지 주소 구성을 참조하십시오.

Forward-count

이 큐가 현재 소비자에게 전달하는 메시지 수입니다. 런타임 시 이용 가능.

Durable

큐가 지속되는지 여부입니다. 지속적 서브스크립션에 대한 자세한 내용은 메시징 스타일을 참조하십시오.

항목

큐가 바인딩될 JNDI 이름 목록입니다. 필수 항목입니다.

expiry-address

만료된 메시지를 수신할 주소입니다. 자세한 내용은 메시지 만료 구성을 참조하십시오.

legacy-entries

큐가 바인딩될 JNDI 이름입니다.

message-count

이 큐에 현재 있는 메시지 수입니다. 런타임 시 이용 가능.

messages-added

생성된 이후 이 큐에 추가된 메시지 수입니다. 런타임 시 이용 가능.

일시 중지됨

큐가 일시 중지되었는지 여부입니다. 런타임 시 이용 가능.

queue-address

큐 주소는 라우팅 메시지에 사용되는 주소를 정의합니다. 주소 설정에 대한 자세한 내용은 주소 설정 구성을 참조하십시오. 필수 항목입니다.

Scheduled-count

이 큐에서 예약된 메시지 수입니다. 런타임 시 이용 가능.

선택기

대기열 선택기입니다. 선택기에 대한 자세한 내용은 필터 표현식 및 메시지 선택기를 참조하십시오.

임시

대기열이 일시적인지 여부. 자세한 내용은 임시 대기열 및 런타임 대기열 을 참조하십시오.

4.2. 주제 추가
링크 복사

주제를 추가하거나 읽는 것은 큐를 추가하는 것과 비슷합니다. 

jms-topic add --topic-address=myTopic --entries=[topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic]
Copy to Clipboard Toggle word wrap

주제 속성 읽기

topic 속성 읽기에는 큐에 사용된 것과 유사한 구문도 있습니다. 

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

entries
  topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic
legacy-entries=n/a
Copy to Clipboard Toggle word wrap 
/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
    }
}
Copy to Clipboard Toggle word wrap

jms-topic의 속성

관리 CLI는 다음 명령에 따라 jms-topic 구성 요소의 모든 속성을 표시합니다. 

/subsystem=messaging-activemq/server=default/jms-topic=*:read-resource-description()
Copy to Clipboard Toggle word wrap

아래 표에는 jms-topic:

Expand
속성설명

Forward-count

이 큐가 현재 소비자에게 전달하는 메시지 수입니다. 런타임 시 이용 가능.

durable-message-count

이 항목의 모든 지속적 구독자에 대한 메시지 수입니다. 런타임 시 이용 가능.

durable-subscription-count

이 항목의 지속적 서브스크립션 가입 수. 런타임 시 이용 가능.

항목

주제가 바인딩될 JNDI 이름입니다. 필수 항목입니다.

legacy-entries

주제가 바인딩될 레거시 JNDI 이름입니다.

message-count

이 큐에 현재 있는 메시지 수입니다. 런타임 시 이용 가능.

messages-added

생성된 이후 이 큐에 추가된 메시지 수입니다. 런타임 시 이용 가능.

non-durable-message-count

이 항목에 대한 비내구성 구독자에 대한 메시지 수입니다. 런타임 시 이용 가능.

비내림-서브스크립션-count

이 주제에 대한 비내구성 구독자 수. 런타임 시 이용 가능.

subscription-count

이 주제의 (내구성 및 비내구성) 구독자 수. 런타임 시 이용 가능.

임시

주제가 일시적인지 여부.

topic-address

주제가 가리키는 주소입니다. 필수 항목입니다.

4.3. JNDI 항목 및 클라이언트
링크 복사

원격 클라이언트가 조회할 수 있으려면 큐 또는 토픽을 java:jboss/exported 네임스페이스에 바인딩해야 합니다. 클라이언트는 조회를 수행할 때 java:jboss/exported/ 뒤의 텍스트를 사용해야 합니다. 예를 들어 testQueue 라는 큐에는 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
Copy to Clipboard Toggle word wrap 
jms-topic --help --commands
Copy to Clipboard Toggle word wrap

모든 소비자를 일시 중지하여 주제를 일시 중지할 수 있습니다. 주제가 일시 중지되는 동안 등록된 새 서브스크립션이 있는 경우 해당 항목도 일시 중지됩니다.

주제의 구독자는 일시 중지된 주제에서 새 메시지를 받지 않습니다. 그러나 일시 중지된 주제는 계속 전송된 메시지를 수신할 수 있습니다. 주제를 다시 시작하면 대기 중인 메시지가 구독자에게 전달됩니다.

persist 매개 변수를 사용하여 브로커를 다시 시작해야도 주제의 상태를 저장할 수 있습니다.

4.5. 주제 일시 중지
링크 복사

주제의 모든 구독자가 일시 중지된 주제에서 새 메시지를 수신하지 못하도록 주제를 일시 중지할 수 있습니다.

절차

  • 다음 예에 표시된 대로 주제를 일시 중지합니다. 

    /subsystem=messaging-activemq/server=default/jms-topic=topic:pause()
{
    "outcome" => "success",
    "result" => undefined
}
    Copy to Clipboard Toggle word wrap

    일시 중지된 주제는 다음 예에 나와 있습니다. 

    /subsystem=messaging-activemq/server=default/jms-topic=topic:read-attribute(name=paused)
{
    "outcome" => "success",
    "result" => true
}
    Copy to Clipboard Toggle word wrap

4.6. 주제 다시 시작
링크 복사

일시 중지된 주제를 다시 시작할 수 있습니다. 주제를 다시 시작하면 일시 중지된 동안 수신한 주제가 서브스크립션자에게 전달됩니다.

절차

  • 다음 예에 표시된 대로 주제를 다시 시작합니다. 

    /subsystem=messaging-activemq/server=default/jms-topic=topic:resume()
{
    "outcome" => "success",
    "result" => undefined
}
    Copy to Clipboard Toggle word wrap

    재개된 주제는 다음 예에 나와 있습니다. 

    /subsystem=messaging-activemq/server=default/jms-topic=topic:read-attribute(name=paused)
{
    "outcome" => "success",
    "result" => false
}
    Copy to Clipboard Toggle word wrap

5장. 로깅 구성
링크 복사

org.apache. activemq 의 JBoss EAP 로깅 하위 시스템에서 로그 범주를 추가하고 원하는 로그 수준을 설정하여 messaging-activemq 하위 시스템에 대한 로깅 을 구성할 수 있습니다. 로그 메시지가 기록되는 방법을 구성하도록 범주의 로그 핸들러를 구성할 수도 있습니다.

XA 트랜잭션에 관한 로그에 대한 자세한 정보를 보려면 com.arspringa 카테고리 의 로그 수준을 TRACE 또는 DEBUG 와 같은 보다 자세한 설정으로 변경합니다.

범주 및 기타 옵션에 대한 구성을 비롯한 로깅에 대한 자세한 내용은 JBoss EAP 구성 가이드의 로깅 섹션을 참조하십시오.

Expand
표 5.1. 로깅 카테고리
로그를 원하는 경우…​이 카테고리를 사용하십시오...​

XA 트랜잭션

com.arllya

모든 메시징 활동

org.apache.activemq

메시징 저널 호출 전용

org.apache.activemq.artemis.journal

자카르타 메시징 호출 전용

org.apache.activemq.artemis.jms

메시징 utils 호출만

org.apache.activemq.artemis.utils

메시징 코어 서버 전용

org.apache.activemq.artemis.core.server

로깅을 위한 클라이언트 구성

다음 단계에 따라 메시징 클라이언트를 구성합니다.

  1. JBoss Jakarta Messaging 클라이언트 및 로그 관리자에 종속 항목을 다운로드합니다.

    Maven을 사용하는 경우 pom.xml 파일에 다음 종속성을 추가합니다. 

    <dependencies>
  ...
  <dependency>
     <groupId>org.jboss.logmanager</groupId>
     <artifactId>jboss-logmanager</artifactId>
     <version>1.5.3.Final</version>
  </dependency>
  <dependency>
      <groupId>org.jboss.eap</groupId>
      <artifactId>wildfly-jms-client-bom</artifactId>
      <type>pom</type>
  </dependency>
  ...
</dependencies>
    Copy to Clipboard Toggle word wrap

    자세한 내용은 JBoss EAP 개발 가이드에서 Maven을 사용하여 에 대한 섹션을 참조하십시오.

  2. 로거에 대한 속성 파일을 만듭니다. 이름을 logging.properties 로 지정하고 알려진 위치에 저장합니다. 다음은 예제 속성 파일입니다. 클라이언트 측의 로깅 옵션 구성에 대한 자세한 내용은 JBoss EAP 개발 가이드 의 로깅 섹션을 참조하십시오. 

    # Root logger option
loggers=org.jboss.logging,org.apache.activemq.artemis.core.server,org.apache.activemq.artemis.utils,org.apache.activemq.artemis.journal,org.apache.activemq.artemis.jms,org.apache.activemq.artemis.ra

# Root logger level
logger.level=INFO
# Apache ActiveMQ Artemis logger levels
logger.org.apache.activemq.artemis.jms.level=INFO
logger.org.apache.activemq.artemis.journal.level=INFO
logger.org.apache.activemq.artemis.utils.level=INFO
logger.org.apache.activemq.artemis.core.server.level=INFO

# Root logger handlers
logger.handlers=FILE

# File handler configuration
handler.FILE=org.jboss.logmanager.handlers.FileHandler
handler.FILE.level=FINE
handler.FILE.properties=autoFlush,fileName
handler.FILE.autoFlush=true
handler.FILE.fileName=activemq.log
handler.FILE.formatter=PATTERN

# Formatter pattern configuration
formatter.PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.PATTERN.properties=pattern
formatter.PATTERN.pattern=%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n
    Copy to Clipboard Toggle word wrap

  3. 예상되는 매개 변수로 클라이언트를 시작합니다. java 명령을 사용하여 클라이언트 코드를 시작하는 경우 다음 매개변수를 추가합니다.

    1. JBoss 클라이언트 및 로거 JAR을 클래스 경로에 추가합니다. 

      -cp /PATH/TO/jboss-client.jar:/PATH/TO/jboss-logmanager.jar
      Copy to Clipboard Toggle word wrap

    2. JBoss 로깅 관리자를 활성화합니다. 

      -Djava.util.logging.manager=org.jboss.logmanager.LogManager
      Copy to Clipboard Toggle word wrap

    3. 로깅 속성 파일의 위치를 설정합니다. 

      -Dlogging.configuration=/PATH/TO/logging.properties
      Copy to Clipboard Toggle word wrap

    클라이언트를 시작하는 전체 명령은 다음 예와 같이 표시됩니다. 

$ java -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dlogging.configuration=/PATH/TO/logging.properties -cp /PATH/TO/jboss-client.jar:/PATH/TO/jboss-logmanager.jar org.example.MyClient
Copy to Clipboard Toggle word wrap

6장. 주소 설정
링크 복사

messaging-activemq 하위 시스템에는 메시지 전달 방법 및 시기, 수행해야 하는 시도 수 및 메시지가 만료되는 시기를 제어하는 여러 구성 가능한 옵션이 있습니다. 이러한 구성 옵션은 모두 <address-setting> 구성 요소 내에 있습니다. 와일드카드 구문을 사용하여 단일 <address-setting> 을 여러 대상에 적용하도록 JBoss EAP를 구성할 수 있습니다.

6.1. 와일드카드 구문
링크 복사

와일드카드를 사용하면 별표 문자인 * 를 사용하는 시스템 수와 마찬가지로 단일 문과 유사한 주소를 일치시켜 여러 파일이나 문자열과 단일 쿼리를 일치시킬 수 있습니다. 다음 테이블에는 <address-setting> 을 정의하는 데 사용할 수 있는 특수 문자가 나열되어 있습니다.

Expand
표 6.1. Jakarta Messaging Wildcard Syntax
문자설명

. (단일 기간)

와일드카드 표현식에서 단어 간 공백을 나타냅니다.

# (플래드 또는 해시 기호)

는 0개 이상의 단어로 이루어진 모든 시퀀스와 일치합니다.

* (별표)

단일 단어와 일치합니다.

아래 표의 예제에서는 주소 집합과 일치하도록 와일드카드를 사용하는 방법을 보여줍니다.

Expand
표 6.2. 자카르타 메시징 와일드카드 예
예제설명

news.europe. #

news.europe,news.europe.sport,news.europe.politics.fr 과 일치하지만 news.usa 또는 europe 와 일치하지 않습니다.

뉴스.*

news.europe 및 news.usa 와 일치하지만 news.europe.sport 와 일치하지 않습니다.

news.*.sport

news.europe.sport 및 news.usa.sport 와 일치하지만 news.europe.fr.sport 와 일치하지 않습니다.

6.2. 기본 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>
Copy to Clipboard Toggle word wrap
참고

name 속성에 단일 # 을 사용하면 # 이 모든 주소와 일치하므로 이 기본 address-setting 이 모든 대상에 사용되는 구성을 설정합니다. 이러한 범용 구성을 모든 주소에 계속 적용하거나, 자체 구성 세트가 필요한 각 주소 또는 주소 그룹에 대해 새 address-setting 을 추가할 수 있습니다.

관리 CLI를 사용하여 주소 설정 구성

주소 설정 구성은 관리 CLI 또는 관리 콘솔을 사용하여 수행되지만 관리 CLI는 편집을 위해 더 많은 구성 특성을 노출합니다. 속성 전체 목록은 이 가이드의 부록에 있는 Address Setting Attributes 를 참조하십시오.

새 address-setting 추가

필요한 경우 add 작업을 사용하여 새 주소 설정을 생성합니다. 관리 CLI 세션의 루트에서 이 명령을 실행할 수 있습니다. 다음 예제에서는 이라고 하는 새 패턴을 생성합니다. address-setting 에 대한 구성 속성을 포함할 수 있습니다. 아래에는 이전에 생성된 DLQ .news 대기열로 설정된 dead-letter-address 특성으로 news.europe. # 과 일치하는 새로운 address-setting 이 생성됩니다. full 프로필을 사용하는 독립 실행형 서버와 관리형 서버 도메인의 예는 각각 표시됩니다. 

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:add(dead-letter-address=DLQ.news)
Copy to Clipboard Toggle word wrap 
/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:add(dead-letter-address=DLQ.news)
Copy to Clipboard Toggle word wrap
address-setting 특성 편집

write-attribute 작업을 사용하여 속성에 새 값을 씁니다. 탭 완성 기능을 사용하여 입력할 때 명령 문자열을 완료하고 사용 가능한 특성을 노출할 수 있습니다. 다음 예제에서는 max-delivery-attempts 값을 10 으로 업데이트합니다. 

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:write-attribute(name=max-delivery-attempts,value=10)
Copy to Clipboard Toggle word wrap 
/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:write-attribute(name=max-delivery-attempts,value=10)
Copy to Clipboard Toggle word wrap
address-setting 속성 읽기

서버 모델에서 활성 상태의 현재 값을 모두 표시하도록 include -runtime=true 매개 변수로 read-resource 작업을 실행하여 값이 변경되었는지 확인합니다. 

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

관리 콘솔을 사용하여 주소 설정 구성

관리 콘솔을 사용하여 다음 단계에 따라 주소 설정을 생성하고 검토할 수 있습니다.

  1. 관리 콘솔에 로그인합니다.
  2. 화면 상단에서 Configuration(구성 ) 탭을 선택합니다. 관리형 도메인을 실행하는 경우 업데이트할 프로필을 선택합니다.
  3. Messaging (ActiveMQ) → Server 를 선택합니다.
  4. 메시징 서버 선택. 기본 구성에서는 default 라는 하나의 서버만 표시됩니다.
  5. Destinations (대상)를 선택하고 View(보기 )를 클릭합니다.
  6. Address Setting(주소 설정 ) 탭을 선택하여 주소 설정을 구성합니다.

새 패턴을 추가할 때(예: news.europe.# ) Pattern 필드는 address-setting 요소의 name 속성을 참조합니다. 관리 CLI를 사용하여 속성을 읽거나 쓸 때 이 값을 입력합니다.

관리 콘솔을 사용하는 동안 dead-letter-address,expiry-address,redelivery-delay, max-delivery-attempts 특성만 편집할 수 있습니다. 다른 속성은 관리 CLI를 사용하여 구성해야 합니다.

메시징 서버에 대한 글로벌 리소스 사용 구성

address-setting 요소의 세 가지 속성은 메시징 서버의 글로벌 리소스 사용량을 제어하는 데 도움이 됩니다.

Expand
속성설명

global-max-memory-size

Artemis가 전체로 간주되고 address -full-policy 가 적용되기 전에 Artemis가 주소에 대한 메시지를 저장하는 데 사용할 수 있는 최대 메모리 양을 제어합니다. 기본값은 -1 이며 제한이 없음을 나타냅니다.

global-max-disk-usage

Artemis가 파일 시스템에 데이터를 저장하는 데 사용할 수 있는 최대 공간을 제어합니다. 제한에 도달하면 새 메시지가 차단됩니다. 이 속성은 디스크에서 사용 가능한 공간의 백분율로 표시됩니다. 최소값은 0% 이고 최대값은 100% 입니다. 기본값은 100% 입니다.

disk-scan-period

Artemis가 파일 시스템에서 사용 가능한 공간을 확인하는 빈도를 제어합니다. 기본값은 5000밀리초 입니다.

6.3. last-value Queues
링크 복사

last-value 큐는 잘 정의된 last-value 속성에 대해 동일한 값을 가진 새 메시지를 큐에 배치할 때 메시지를 삭제하는 특수 대기열입니다. 즉, last-value 큐는 마지막 값만 유지합니다. 마지막 값 큐의 일반적인 적용에는 특정 주식의 최신 가격에만 관심이 있는 주가가 포함될 수 있습니다.

중요

큐에 페이징이 활성화된 경우 last-value 큐가 예상대로 작동하지 않습니다. last-value 큐를 사용하기 전에 페이징을 비활성화해야 합니다.

마지막 값 대기열 구성

last-value 큐는 address-setting 구성 요소 내에 정의됩니다. 

<address-setting name="jms.queue.lastValueQueue" last-value-queue="true" />
Copy to Clipboard Toggle word wrap

관리 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
}
Copy to Clipboard Toggle word wrap

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)
Copy to Clipboard Toggle word wrap
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);
Copy to Clipboard Toggle word wrap
  • 그런 다음 동일한 last-value를 사용하여 다른 메시지를 큐로 보냅니다. 
message = session.createTextMessage("My 2nd message with the last-value property set");
message.setStringProperty("_AMQ_LVQ_NAME", "MY_MESSAGE");
producer.send(message);
Copy to Clipboard Toggle word wrap
  • 그런 다음 소비자는 last-value를 사용하여 메시지를 받습니다. 
TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
System.out.format("Received message: %s\n", messageReceived.getText());
Copy to Clipboard Toggle word wrap

위의 예에서 두 메시지 모두 _AMQ_LVQ_NAME을 " MY_ MESSAGE"로 설정하고 두 번째 메시지는 첫 번째 후 대기열에서 수신되었으므로 클라이언트의 출력은 "마지막 값 속성이 설정된 내 2 번째 메시지" 입니다.

7장. 보안 구성
링크 복사

7.1. 원격 연결 보안
링크 복사

7.1.1. 레거시 보안 하위 시스템 사용
링크 복사

JBoss EAP에서 레거시 보안 하위 시스템을 사용하여 messaging-activemq 하위 시스템을 보호할 수 있습니다. 레거시 보안 하위 시스템은 레거시 보안 영역 및 도메인을 사용합니다. 보안 영역 및 보안 도메인에 대한 자세한 내용은 JBoss EAP 보안 아키텍처 가이드를 참조하십시오. messaging-activemq 하위 시스템은 ApplicationRealm 이라는 보안 영역과 other 라는 보안 도메인을 사용하도록 미리 구성되어 있습니다.

참고

레거시 보안 하위 시스템 접근 방식은 JBoss EAP 7.0의 기본 구성입니다.

The ApplicationRealm 은 구성 파일 상단에 정의되어 있습니다. 

<management>
  <security-realms>
      ...
       <security-realm name="ApplicationRealm">
          <authentication>
              <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
              <properties
                path="application-users.properties"
                relative-to="jboss.server.config.dir" />
          </authentication>
          <authorization>
              <properties
                path="application-roles.properties"
                relative-to="jboss.server.config.dir" />
          </authorization>
       </security-realm>
  </security-realms>
  ...
</management>
Copy to Clipboard Toggle word wrap

이름에서 알 수 있듯이 ApplicationRealm 은 JBoss EAP의 모든 애플리케이션 중심 하위 시스템(예: messaging-activemq,undertow, ejb3 하위 시스템)에 대한 기본 보안 영역입니다. ApplicationRealm 은 로컬 파일 시스템을 사용하여 사용자 이름과 해시된 암호를 저장합니다. 편의를 위해 JBoss EAP에는 ApplicationRealm 에 사용자를 추가하는 데 사용할 수 있는 스크립트가 포함되어 있습니다. 자세한 내용은 JBoss EAP 에서 서버 보안 구성 가이드의 기본 사용자 구성을 참조하십시오.

other 보안 도메인은 messaging-activemq 와 같은 애플리케이션 관련 하위 시스템의 기본 보안 도메인입니다. 구성에서 명시적으로 선언되지 않지만 다음 관리 CLI 명령을 사용하여 messaging-activemq 하위 시스템에서 사용하는 보안 도메인을 확인할 수 있습니다. 

/subsystem=messaging-activemq/server=default:read-attribute(name=security-domain)
{
    "outcome" => "success",
    "result" => "other"
}
Copy to Clipboard Toggle word wrap

다음이 사용되는 보안 도메인을 업데이트할 수도 있습니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=security-domain, value=mySecurityDomain)
Copy to Clipboard Toggle word wrap

JBoss EAP 서버 보안 구성 방법 가이드에는 새 보안 영역 및 도메인을 생성하는 방법에 대한 자세한 내용이 있습니다. 지금은 다른 도메인이 구성에 어떻게 표시되는지 알 수 있습니다. 

<subsystem xmlns="urn:jboss:domain:security:2.0">
     <security-domains>
         <security-domain name="other" cache-type="default">
             <authentication>
                 <login-module code="Remoting" flag="optional">
                     <module-option name="password-stacking" value="useFirstPass"/>
                 </login-module>
                 <login-module code="RealmDirect" flag="required">
                     <module-option name="password-stacking" value="useFirstPass"/>
                 </login-module>
             </authentication>
         </security-domain>
         ...
     <security-domains>
 </subsystem>
Copy to Clipboard Toggle word wrap

'other' 도메인은 두 개의 로그인 모듈을 인증의 수단으로 사용합니다. 첫 번째 모듈인 Remoting 은 원격 Jakarta Enterprise Bean 호출을 인증하는 반면 RealmDirect 모듈은 지정된 영역에 정의된 정보 저장소를 사용하여 사용자를 인증합니다. 이 경우 영역이 선언되지 않으므로 기본 realm ApplicationRealm 이 사용됩니다. 각 모듈에는 password-stacking 옵션이 useFirstPass 로 설정되어 있으며, 이는 인증된 사용자의 주체 이름과 암호를 저장하도록 로그인 모듈에 지시합니다. 로그인 모듈 및 옵션에 대한 자세한 내용은 JBoss EAP 로그인 모듈 참조를 참조하십시오.

역할 기반 액세스는 주소 수준에서 구성되어 있습니다. 주소에 대한 역할 기반 보안을 참조하십시오.

7.1.2. Elytron 하위 시스템 사용
링크 복사

elytron 하위 시스템을 사용하여 messaging-activemq 하위 시스템을 보안할 수도 있습니다. How to Configure Identity Management 가이드의 elytron 하위 시스템 사용 및 Elytron 보안 도메인을 만드는 방법에 대한 자세한 내용은 How to Configure Identity Management guide에서 확인할 수 있습니다. https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/how_to_configure_identity_management/index.xml#elytron_secure_apps

Elytron 보안 도메인을 사용하려면 다음을 수행합니다.

  1. 레거시 보안 도메인 정의를 해제합니다. 

    /subsystem=messaging-activemq/server=default:undefine-attribute(name=security-domain)
    Copy to Clipboard Toggle word wrap

  2. Elytron 보안 도메인 설정. 

    /subsystem=messaging-activemq/server=default:write-attribute(name=elytron-domain, value=myElytronSecurityDomain)

reload
    Copy to Clipboard Toggle word wrap
7.1.2.1. 관리 콘솔을 사용하여 Elytron 보안 도메인 설정
링크 복사

관리 콘솔을 사용하여 Elytron 보안 도메인을 설정하려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔을 참조하십시오.
  2. Configuration → Subsystems → Messaging (ActiveMQ) → Server → default 로 이동하여 보기를 클릭합니다.
  3. Security (보안) 탭으로 이동하여 Edit(편집 )를 클릭합니다.
  4. Elytron Domain(Elytron 도메인 ) 값 추가 또는 편집.
  5. Save(저장 )를 클릭하여 변경 사항을 저장합니다.
  6. 변경 사항을 적용하려면 서버를 다시 로드합니다.
참고

security-domain 또는 elytron-domain 만 정의할 수 있지만 동시에 둘 다 정의할 수는 없습니다. 둘 다 정의되지 않은 경우 JBoss EAP는 다른 레거시 보안 도메인에 매핑되는 기타 의 security-domain 기본값을 사용합니다.

7.1.3. 전송 보안
링크 복사

JBoss EAP 메시징과 함께 제공되는 기본 http-connector 는 기본적으로 보안되지 않습니다. 메시지 전송을 보호하고 지침에 따라 SSL/TLS에 대한 웹 트래픽을 활성화하여 How to Configure Server Security for JBoss EAP에서 애플리케이션에 대한 단방향 및 양방향 SSL/TLS를 구성할 수 있습니다.

참고

메시지 전송을 보호하기 위한 위의 접근 방식은 http-acceptor 를 보호하는 데도 작동합니다.

위에서 설명한 대로 전송을 구성할 때 다음 추가 단계를 수행해야 합니다.

  • 기본적으로 모든 HTTP 어셉터는 HTTP 포트에서 수신 대기하는 기본 http-listener 를 사용하도록 구성됩니다. HTTPS 포트에서 수신 대기하는 https-listener 를 사용하도록 HTTP 어셉터를 구성해야 합니다.
  • 모든 HTTP 커넥터의 socket-binding 요소는 http 대신 https 를 사용하도록 업데이트해야 합니다.
  • SSL/TLS를 통해 통신하는 각 http-connector 는 ssl-enabled 매개 변수를 true 로 설정해야 합니다.
  • HTTP 커넥터를 다른 서버에 연결하는 데 사용하는 경우 trust-store 및 키 저장소와 같은 관련 매개 변수를 구성해야 합니다. http-connector 를 보호하려면 원격 커넥터 보안에 문서화된 remote-connector 로 수행하는 것과 동일한 매개변수를 구성해야 합니다.

메시징 전송을 위한 어셉터 및 커넥터 구성 정보는 메시징 전송 구성을 참조하십시오.

7.1.4. 원격 커넥터 보안
링크 복사

기본 http-connector 를 사용하지 않고 대신 TCP 통신 용 원격 연결기 및 원격 어셉터를 생성한 경우 아래 표의 속성을 사용하여 SSL/TLS에 대해 각각 구성할 수 있습니다. 속성은 구성에서 어셉터 또는 커넥터의 하위 <param> 요소의 일부로 표시됩니다.

일반적으로 서버는 개인 SSL/TLS 키를 소유하고 해당 공개 키를 클라이언트와 공유합니다. 이 시나리오에서 서버는 remote- acceptor에 key-store -path 및 key-store- password 매개 변수를 정의합니다. 각 클라이언트에는 다른 위치에 있는 truststore가 있을 수 있고 다른 암호로 암호화될 수 있으므로 remote-connector 에 trust-store-path 및 trust-store-password 속성을 지정하는 것은 권장되지 않습니다. 대신 시스템 속성 javax.net.ssl.trustStore 및 javax.net.ssl.trustStore Password 를 사용하여 클라이언트 측에서 이러한 매개 변수를 구성합니다. remote-connector 에 대해 구성해야 하는 매개변수는 ssl-enabled=true 이고 DefaultSslContext=true를 사용합니다. 그러나 서버가 remote-connector 를 사용하여 다른 서버에 연결하는 경우 remote-connector 의 trust-store-path 및 trust-store-password 매개변수를 설정하는 것이 좋습니다.

위의 사용 사례에서는 다음 관리 CLI 명령을 사용하여 remote-acceptor 를 생성합니다. 

/subsystem=messaging-activemq/server=default/remote-acceptor=mySslAcceptor:add(socket-binding=netty,params={ssl-enabled=true, key-store-path=PATH/TO/server.jks, key-store-password=${VAULT::server-key::key-store-password::sharedKey}})
Copy to Clipboard Toggle word wrap

위의 사용 사례에서 remote-connector 를 생성하려면 다음 관리 CLI 명령을 사용합니다. 

/subsystem=messaging-activemq/server=default/remote-connector=mySslConnector:add(socket-binding=netty,params={ssl-enabled=true, useDefaultSslContext=true})
Copy to Clipboard Toggle word wrap

관리 CLI를 사용하면 기존 remote -acceptor 또는 remote- connector 에 매개변수를 추가할 수도 있습니다. 

/subsystem=messaging-activemq/server=default/remote-connector=myOtherSslConnector:map-put(name=params,key=ssl-enabled,value=true)
Copy to Clipboard Toggle word wrap

remote-acceptor 및 remote-connector 는 모두 socket-binding 을 참조하여 통신에 사용할 포트를 선언합니다. 소켓 바인딩 및 어셉터 및 커넥터와 의 관계는 메시징 하위 시스템 구성 개요 를 참조하십시오.

Expand
표 7.1. NettyConnectorFactory의 SSL/TLS 관련 구성 속성
속성설명

enabled-cipher-suites

를 사용하여 어셉터 또는 커넥터를 구성할 수 있습니다. SSL/TLS 통신에 사용되는 암호화 제품군의 쉼표로 구분된 목록입니다. 기본값은 null이며 JVM의 기본값이 사용됩니다.

enabled-protocols

를 사용하여 어셉터 또는 커넥터를 구성할 수 있습니다. SSL/TLS 통신에 사용되는 쉼표로 구분된 프로토콜 목록입니다. 기본값은 null이며 JVM의 기본값이 사용됩니다.

key-store-password

어셉터에서 사용하는 경우 이는 서버 측 키 저장소의 암호입니다.

커넥터에서 사용하는 경우 클라이언트 측 키 저장소의 암호입니다. 양방향 SSL/TLS를 사용하는 경우에만 커넥터와 관련이 있습니다. 서버에서 이 값을 구성할 수 있지만 클라이언트가 다운로드하여 사용합니다.

클라이언트가 서버에 설정된 다른 암호를 사용해야 하는 경우 표준 javax.net.ssl.keyStorePassword 시스템 속성을 사용하여 서버 측 설정을 재정의할 수 있습니다. 클라이언트의 다른 구성 요소가 표준 시스템 속성을 이미 사용하고 있는 경우 org.apache.activemq.ssl.keyStorePassword 속성을 사용합니다.

key-store-path

어셉터에서 사용하는 경우 서버의 인증서를 보유한 서버의 SSL/TLS 키 저장소에 대한 경로입니다. 자체 서명 또는 기관에서 서명한 인증서에는 를 사용합니다.

커넥터에서 사용하는 경우 클라이언트 인증서를 보유한 클라이언트 측 SSL/TLS 키 저장소에 대한 경로입니다. 양방향 SSL/TLS를 사용하는 경우에만 커넥터와 관련이 있습니다.

이 값은 서버에 구성되어 있지만 클라이언트가 다운로드하여 사용합니다. 클라이언트가 서버에 설정된 것과 다른 경로를 사용해야 하는 경우 표준 javax.net.ssl.keyStore 시스템 속성을 사용하여 서버 측 설정을 재정의할 수 있습니다. 클라이언트의 다른 구성 요소가 표준 속성을 이미 사용하고 있는 경우 org.apache.activemq.ssl.keyStore 시스템 속성을 사용합니다.

key-store-provider

키가 저장되는 파일의 형식을 정의합니다(예: PKCS11 또는 PKCS12). 허용되는 값은 JDK에 따라 다릅니다.

needs-client-auth

이 속성은 어셉터 전용입니다. 이 어셉터에 연결하는 클라이언트에 양방향 SSL/TLS가 필요함을 알려줍니다. 유효한 값은 true 또는 false입니다. 기본값은 false 입니다.

SSL 지원

SSL/TLS를 사용하려면 true 여야 합니다. 기본값은 false 입니다.

trust-store-password

어셉터에서 사용하는 경우 서버 측 신뢰 저장소의 암호입니다. 이는 양방향 SSL/TLS를 사용하는 경우에만 어셉터와 관련이 있습니다.

커넥터에 사용하면 클라이언트 측 신뢰 저장소의 암호입니다. 서버에서 이 값을 구성할 수 있지만 클라이언트가 다운로드하여 사용합니다.

클라이언트에서 서버에 설정된 것과 다른 암호를 사용해야 하는 경우 표준 javax.net.ssl.trustStorePassword 시스템 속성을 사용하여 서버 측 설정을 재정의할 수 있습니다. 클라이언트의 다른 구성 요소가 표준 속성을 이미 사용하고 있는 경우 org.apache.activemq.ssl.trustStorePassword 시스템 속성을 사용합니다.

trust-store-path

어셉터에서 사용하는 경우 서버가 신뢰하는 모든 클라이언트의 키를 포함하는 서버 측 SSL/TLS 키 저장소의 경로입니다. 이는 양방향 SSL/TLS를 사용하는 경우에만 어셉터와 관련이 있습니다.

커넥터에 사용되는 경우 클라이언트가 신뢰하는 모든 서버의 공개 키를 보유하는 클라이언트 측 SSL/TLS 키 저장소의 경로입니다. 서버에서 이 값을 구성할 수 있지만 클라이언트가 다운로드하여 사용합니다.

클라이언트에서 서버에 설정된 것과 다른 경로를 사용해야 하는 경우 표준 javax.net.ssl.trustStore 시스템 속성을 사용하여 서버 측 설정을 재정의할 수 있습니다. 클라이언트의 다른 구성 요소가 표준 시스템 속성을 이미 사용하고 있는 경우 org.apache.activemq.ssl.trustStore 시스템 속성을 사용합니다.

trust-store-provider

키가 저장되는 파일의 형식을 정의합니다(예: PKCS11 또는 PKCS12). 허용되는 값은 JDK에 따라 다릅니다.

7.2. 대상 보안
링크 복사

메시징 서버에 대한 원격 연결 보안 외에도 특정 대상에 대한 보안을 구성할 수도 있습니다. 이는 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
        }}}}
    }
}
Copy to Clipboard Toggle word wrap

security-setting 옵션은 이름 필드에 와일드카드를 사용하여 보안 제약 조건을 적용할 대상을 처리합니다. 단일 # 의 값은 모든 주소와 일치합니다. 보안 제약 조건에서 와일드카드 사용에 대한 자세한 내용은 주소에 대한 역할 기반 보안을 참조하십시오.

7.2.1. 주소에 대한 역할 기반 보안
링크 복사

JBoss EAP 메시징에는 주소를 기반으로 큐에 보안을 적용하기 위한 유연한 역할 기반 보안 모델이 포함되어 있습니다.

핵심 JBoss EAP 메시징 서버는 주로 주소에 바인딩된 큐 세트로 구성됩니다. 메시지가 주소로 전송되면 서버는 먼저 해당 주소에 바인딩된 큐 집합을 조회한 다음 메시지를 바인딩된 큐로 라우팅합니다.

JBoss EAP 메시징에는 주소에 따라 큐에 적용할 수 있는 권한 집합이 있습니다. 주소의 정확한 문자열 일치를 사용하거나 와일드카드 일치를 사용할 수 있습니다. 와일드카드 문자 # 및 *. 와일드카드 구문 을 사용하는 방법에 대한 자세한 내용은 주소 설정을 참조하십시오.

각 security-setting 에 대해 여러 역할을 만들 수 있으며 역할에 적용할 수 있는 7개의 권한 설정이 있습니다. 다음은 사용 가능한 전체 권한 목록입니다.

  • create-durable-queue 를 사용하면 역할이 일치하는 주소 아래에 지속형 큐를 만들 수 있습니다.
  • delete-durable-queue 를 사용하면 역할이 일치하는 주소 아래의 지속형 큐를 삭제할 수 있습니다.
  • create-non-durable-queue 를 사용하면 역할이 일치하는 주소 아래에 비내구성 대기열을 만들 수 있습니다.
  • delete-non-durable-queue 를 사용하면 역할에서 일치하는 주소에서 비내구성 큐를 삭제할 수 있습니다.
  • send 를 사용하면 역할이 일치하는 주소로 메시지를 보낼 수 있습니다.
  • 를 사용하면 역할에서 일치하는 주소에 바인딩된 큐의 메시지를 사용할 수 있습니다.
  • manage 를 사용하면 관리 메시지를 관리 주소로 보내 관리 작업을 호출할 수 있습니다.
역할 기반 보안 구성

security-setting에 역할 기반 보안을 사용하려면 먼저 하나를 만들어야 합니다. 예를 들어, 아래에 news.europe.# 의 security-setting 이 생성됩니다. news.europe. fr 또는 news.europe. tech.uk와 같이 news.europe. fr 로 시작하는 모든 목적지에 적용됩니다. 

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

그런 다음 생성한 security-setting 에 역할을 추가하고 권한을 선언합니다. 아래 예제에서 dev 역할은 생성되고 사용할 수 있는 권한을 부여하고, 큐로 보내고, 보류 불가능한 큐를 만들고 삭제할 수 있습니다. 기본값은 false 이므로 전환하려는 권한에 대해서만 JBoss EAP에 알려야 합니다. 

/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"}
Copy to Clipboard Toggle word wrap

권한 사용을 자세히 설명하기 위해 아래 예제에서는 admin 역할을 만들고 관리 권한을 전환하여 관리 메시지를 보낼 수 있습니다. 지속형 큐 생성 및 삭제 권한도 전환됩니다. 

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

security-setting 의 구성을 확인하려면 관리 CLI를 사용합니다. recursive=true 옵션을 사용하여 전체 권한 표시를 가져오십시오. 

/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
            }
        }}
    }
Copy to Clipboard Toggle word wrap

위의 문자열 news.europe. 로 시작하는 주소에 대한 권한은 관리 CLI에 의해 완전히 표시됩니다. 요약하자면, 관리자 역할이 있는 사용자만 지속형 큐를 생성하거나 삭제할 수 있지만 dev 역할이 있는 사용자만 비내구성 큐를 생성하거나 삭제할 수 있습니다. 또한 dev 역할의 사용자는 메시지를 보내거나 사용할 수 있지만 admin 사용자는 메시지를 보내거나 사용할 수 없습니다. 그러나 관리 권한이 true 로 설정되어 있으므로 관리 메시지를 보낼 수 있습니다.

둘 이상의 일치가 주소 집합에 적용되는 경우 더 구체적인 일치가 우선합니다. 예를 들어, news.europe.tech.uk.# 주소는 news.europe.tech.# 보다 구체적입니다. 권한이 상속되지 않기 때문에 단순히 지정하지 않고 보다 구체적인 security-setting 블록에서 권한을 거부할 수 있습니다. 그렇지 않으면 주소의 하위 그룹에서 권한을 거부할 수 없습니다.

사용자와 사용자가 보유한 역할 간의 매핑은 보안 관리자가 처리합니다. JBoss EAP는 디스크의 파일에서 사용자 자격 증명을 읽고 JAAS 또는 JBoss EAP 보안에도 연결할 수 있는 사용자 관리자와 함께 제공됩니다.

보안 관리자 구성에 대한 자세한 내용은 JBoss EAP 보안 아키텍처 가이드를 참조하십시오.

JBoss EAP에서 인증되지 않은 클라이언트를 자동으로 부여하려면 guest 역할에서 다음 두 가지 변경 사항을 수행합니다.

  1. other 보안 도메인에 새 module-option 을 추가합니다. 새 옵션인 unauthenticatedIdentity 는 JBoss EAP에 인증되지 않은 클라이언트에 게스트 액세스 권한을 부여하도록 지시합니다. 이 작업을 수행하는 권장 방법은 관리 CLI를 사용하는 것입니다. 

    /subsystem=security/security-domain=other/authentication=classic/login-module=RealmDirect:map-put(name=module-options,key=unauthenticatedIdentity,value=guest)
{
   "outcome" => "success",
   "response-headers" => {
       "operation-requires-reload" => true,
       "process-state" => "reload-required"
   }
}
    Copy to Clipboard Toggle word wrap

    명령을 실행한 후 서버에 다시 로드해야 합니다. 다음 관리 CLI 명령을 사용하여 새 옵션을 확인할 수 있습니다. 

    /subsystem=security/security-domain=other/authentication=classic/login-module=RealmDirect:read-resource()
{
    "outcome" => "success",
    "result" => {
        "code" => "RealmDirect",
        "flag" => "required",
        "module" => undefined,
        "module-options" => {
            "password-stacking" => "useFirstPass",
            "unauthenticatedIdentity" => "guest"
        }
    }
}
    Copy to Clipboard Toggle word wrap

    또한 서버 구성 파일은 명령이 실행된 후 다음과 같이 표시되어야 합니다. 

    <subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    <security-domain name="other" cache-type="default">
       <authentication>
         ...
         <login-module code="RealmDirect" flag="required">
            ...
            <module-option name="unauthenticatedIdentity" value="guest"/>
            ...
         </login-module>
         ...
       </authentication>
    </security-domain>
  ...
  </security-domains>
</subsystem>
    Copy to Clipboard Toggle word wrap

  2. # 문자를 삭제하여 파일 application-roles.properties 에서 다음 행의 주석을 제거합니다. 파일은 독립 실행형 서버 또는 도메인 컨트롤러를 사용하는지 여부에 따라 EAP_HOME/standalone/configuration / 또는 EAP_HOME/domain /configuration/에 있습니다. 

    #guest=guest
    Copy to Clipboard Toggle word wrap

이제 원격 클라이언트가 인증하지 않고도 서버에 액세스할 수 있어야 합니다. guest 역할과 연결된 권한이 부여됩니다.

7.3. 자카르타 메시징 개체 메시지 분리 제어
링크 복사

ObjectMessage 에는 잠재적으로 위험한 개체가 포함될 수 있으므로 ActiveMQ Artemis는 신뢰할 패키지 및 클래스를 제어하기 위한 간단한 클래스 필터링 메커니즘을 제공합니다. 클래스가 신뢰할 수 있는 패키지인 오브젝트를 허용 목록에 추가하여 문제 없이 역직렬화할 수 있음을 나타낼 수 있습니다. 클래스가 신뢰할 수 없는 패키지의 오브젝트를 블랙 목록에 추가하여 직렬화되지 않도록 할 수 있습니다.

ActiveMQ Artemis는 다음과 같이 직렬화를 위한 오브젝트를 필터링합니다.

  • 허용 목록과 차단 목록이 비어 있으면 기본값인 모든 serializable 오브젝트를 역직렬화할 수 있습니다.
  • 오브젝트의 클래스 또는 패키지가 차단 목록의 항목 중 하나와 일치하는 경우 역직렬화할 수 없습니다.
  • 오브젝트의 클래스 또는 패키지가 화이트 목록의 항목과 일치하는 경우 역직렬화할 수 있습니다.
  • 오브젝트의 클래스 또는 패키지가 블랙 목록과 허용 목록의 항목과 일치하면 차단 목록의 항목이 우선합니다. 즉, 역직렬화할 수 없습니다.
  • 오브젝트의 클래스 또는 패키지가 차단 목록이나 화이트 목록과 일치하지 않는 경우 허용 목록이 비어 있지 않은 경우 오브젝트 역직렬화가 거부됩니다. 즉, 화이트 목록이 지정되지 않습니다.

전체 이름이 목록의 항목 중 하나와 정확히 일치하는 경우, 패키지가 목록의 항목 중 하나와 일치하는 경우 또는 목록에 있는 항목 중 하나의 하위 패키지인 경우 개체가 일치하는 것으로 간주됩니다.

연결 팩토리와 역직렬화- white-list 및 역직렬화- 검정 목록 속성을 사용하여 pooled-connection- factory 에서 역직렬화할 수 있는 오브젝트를 지정할 수 있습니다. 직렬화-white-list 특성은 역직렬 화할 수 있는 클래스 또는 패키지 목록을 정의하는 데 사용됩니다. deserialization-black-list 특성은 역직렬화할 수 없는 클래스 또는 패키지 목록을 정의하는 데 사용됩니다.

다음 명령은 RemoteConnectionFactory 연결 팩토리의 블랙리스트와 기본 서버에 대한 the 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])
Copy to Clipboard Toggle word wrap

이러한 명령은 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"/>
Copy to Clipboard Toggle word wrap

연결 팩토리 및 풀링된 연결 팩토리에 대한 자세한 내용은 이 가이드 의 연결 팩토리 구성을 참조하십시오.

활성화 속성을 구성하여 MDB에서 역직렬화할 수 있는 오브젝트를 지정할 수도 있습니다. deserializationWhiteList 속성은 역직렬화할 수 있는 클래스 또는 패키지 목록을 정의하는 데 사용됩니다. 직렬화BlackList 속성은 역직렬 화할 수 없는 클래스 또는 패키지 목록을 정의하는 데 사용됩니다. 활성화 속성에 대한 자세한 내용은 JBoss EAP 용 Jakarta Enterprise Beans Applications 개발에서 Deployment Descriptor를 사용하여 MDB 구성을 참조하십시오.

7.4. 권한 부여 Invalidation Management
링크 복사

messaging -activemq 하위 시스템의 서버의 security-invalidation- interval 특성은 작업을 다시 인증하기 전에 권한 부여를 캐시하는 기간을 결정합니다.

시스템이 사용자에게 주소에서 작업을 수행할 수 있는 권한을 부여하면 권한 부여가 캐시됩니다. 다음에 동일한 사용자가 동일한 주소에서 동일한 작업을 수행할 때 시스템은 작업에 캐시된 권한을 사용합니다.

예를 들어 사용자 admin 은 주소 뉴스 로 메시지를 보내려고 합니다. 시스템에서 작업을 인증하고 권한을 캐시합니다. 다음에 관리자가 메시지를 뉴스 로 보내려고 하면 시스템은 캐시된 권한을 사용합니다.

잘못된 간격에 의해 지정된 시간 내에 캐시된 권한 부여가 다시 사용되지 않으면 캐시에서 인증이 지워집니다. 시스템은 요청된 주소에서 요청된 작업을 수행하도록 사용자를 다시 인증해야 합니다.

설치 후 JBoss EAP는 기본값 10000밀리초(10초)로 가정합니다. 

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

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"
    }
}
Copy to Clipboard Toggle word wrap

구성을 수정하려면 서버를 다시 로드해야 합니다.

특성을 읽으면 새 결과가 표시됩니다. 

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

8장. 메시징 전송 구성
링크 복사

이 섹션에서는 JBoss EAP 메시징 전송을 이해하는 데 중요한 개념, 특히 커넥터 및 어셉터에 대해 설명합니다. 어셉터는 서버에서 연결을 수락하는 방법을 정의하는 데 사용되며 커넥터는 클라이언트가 서버에 연결하는 방법을 정의합니다. 각 개념은 차례로 설명된 다음 실제 예제에서는 클라이언트가 JNDI 또는 코어 API를 사용하여 JBoss EAP 메시징 서버에 연결할 수 있는 방법을 보여줍니다.

8.1. 어셉터 및 커넥터 유형
링크 복사

어셉터 및 커넥터의 세 가지 주요 유형은 JBoss EAP 구성에 정의되어 있습니다.

in-vm: In-vm은 Intra Virtual Machine(가상 시스템)의 약어입니다. 클라이언트와 서버가 동일한 JVM(예: JBoss EAP의 동일한 인스턴스에서 실행되는 MDB(Message Driven Beans))에서 실행 중인 경우 이 커넥터 유형을 사용합니다.

http: 클라이언트 및 서버가 다른 JVM에서 실행 중인 경우 사용됩니다. undertow 하위 시스템의 기본 포트를 8080 으로 사용하므로 HTTP를 통해 메시징 통신을 다중화할 수 있습니다. Red Hat은 특히 클라우드 환경에서 포트 관리와 같은 고려 사항으로 인해 클라이언트와 서버가 다른 JVM에서 실행되는 경우 http 커넥터를 사용하는 것이 좋습니다.

remote: 원격 전송은 클라이언트와 서버가 다른 JVM에서 실행될 때 기본 TCP 통신에 사용되는 Netty 기반 구성 요소입니다. http 를 사용할 수 없을 때의 대안.

클라이언트는 서버의 어셉터 중 하나와 호환되는 커넥터를 사용해야 합니다. 예를 들어 in-vm-connector 만 in-vm-acceptor 에 연결할 수 있으며 http-connector 만 http-acceptor 에 연결할 수 있습니다.

read-children-attributes 작업을 사용하여 관리 CLI에 지정된 어셉터 또는 커넥터 유형의 속성을 나열할 수 있습니다. 예를 들어 기본 메시징 서버의 모든 http-connectors 의 속성을 보려면 다음을 입력합니다. 

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=http-connector,include-runtime=true)
Copy to Clipboard Toggle word wrap

모든 http-acceptors 의 속성은 다음과 유사한 명령을 사용하여 읽습니다. 

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=http-acceptor,include-runtime=true)
Copy to Clipboard Toggle word wrap

다른 어셉터 및 커넥터 유형은 동일한 구문을 따릅니다. 어셉터 또는 커넥터 유형(예: remote -connector 또는 in-vm- acceptor )과 함께 하위 유형을 제공합니다.

8.2. 어셉터
링크 복사

어셉터는 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>
Copy to Clipboard Toggle word wrap

위의 구성에서 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>
Copy to Clipboard Toggle word wrap

위의 remote-acceptor 가 existing- 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>
Copy to Clipboard Toggle word wrap

이 예에서 legacy-messaging socket- binding 은 JBoss EAP를 포트 5445 에 바인드하고, 위의 remote-acceptor 는 레거시 클라이언트에서 사용할 messaging-activemq 하위 시스템을 대신하여 포트를 클레임합니다.

마지막으로 in-vm-acceptor 는 server-id 특성에 고유한 값을 사용하므로 이 서버 인스턴스를 동일한 JVM에서 실행할 수 있는 다른 서버와 구분할 수 있습니다.

8.3. 커넥터
링크 복사

커넥터는 통합된 JBoss EAP 메시징 서버에 연결하는 방법을 정의하며 클라이언트에서 연결을 만드는 데 사용됩니다.

클라이언트에서 실제로 커넥터를 사용할 때 커넥터가 서버에 정의된 이유에 대해 궁금할 수 있습니다. 이에 대한 이유는 다음과 같습니다.

  • 경우에 따라 서버가 다른 서버에 연결할 때 클라이언트로 작동할 수 있습니다. 예를 들어 한 서버는 다른 서버로의 브리지 역할을 하거나 클러스터에 참여하려고 할 수 있습니다. 이러한 경우 서버는 다른 서버에 연결하는 방법을 알아야 하며 해당 서버는 커넥터로 정의됩니다.
  • 서버는 JNDI를 사용하여 클라이언트에서 조회하는 ConnectionFactory 를 사용하여 커넥터를 제공할 수 있으므로 서버에 대한 연결을 생성하는 것이 더 간단합니다.

서버당 원하는 개수의 커넥터를 정의할 수 있습니다. 아래 샘플 구성은 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>
Copy to Clipboard Toggle word wrap

full -ha 프로필의 http- acceptor 와 마찬가지로 http-connector 는 undertow 하위 시스템에서 정의한 기본 http-listener 를 사용합니다. 엔드포인트 특성은 연결할 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 와 동일한 값을 사용합니다.

참고

공용 인터페이스의 바인드 주소가 0.0.0.0으로 설정된 경우 JBoss EAP 서버를 시작할 때 로그에 다음 경고가 표시됩니다. 

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.
Copy to Clipboard Toggle word wrap

원격 커넥터가 0.0.0.0 주소를 사용하여 서버에 연결할 수 없고 messaging-activemq 하위 시스템이 서버의 호스트 이름으로 교체하려고 하기 때문입니다. 관리자는 소켓 바인딩에 다른 인터페이스 주소를 사용하도록 원격 커넥터를 구성해야 합니다.

8.4. Acceptor 및 커넥터 구성
링크 복사

커넥터와 어셉터를 위한 다양한 구성 옵션이 있습니다. 구성에 하위 <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)
Copy to Clipboard Toggle word wrap

유사한 구문을 사용하여 매개 변수 값을 검색합니다. 

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

아래 예제와 같이 어셉터 또는 커넥터를 만들 때 매개변수를 포함할 수도 있습니다. 

/subsystem=messaging-activemq/server=default/remote-connector=myRemote:add(socket-binding=mysocket,params={foo=bar,foo2=bar2})
Copy to Clipboard Toggle word wrap
Expand
표 8.1. 전송 구성 속성
속성설명

batch-delay

전송에 패킷을 작성하기 전에 메시징 서버를 구성하여 최대 배치 지연 시간(밀리초)에 대한 쓰기를 일괄 처리하도록 구성할 수 있습니다. 이로 인해 메시지 전송에 대한 평균 대기 시간을 늘려 매우 작은 메시지의 전체 처리량이 증가합니다. 기본값은 0입니다.

direct-deliver

메시지가 서버에 도착하고 대기 소비자에게 전달되면 기본적으로 메시지가 도착한 동일한 스레드에서 배달됩니다. 이렇게 하면 상대적으로 작은 메시지와 적은 수의 소비자가 있는 환경에서 좋은 대기 시간이 제공되지만 처리량과 대기 시간이 줄어듭니다. 가장 높은 처리량의 경우 이 속성을 false 로 설정할 수 있습니다. 기본값은 true입니다.

http-upgrade-enabled

http-connector 에서 HTTP 업그레이드를 사용하므로 HTTP를 통해 메시징 트래픽을 멀티플렉싱하도록 지정합니다. 이 속성은 http-connector 를 생성하고 관리자가 필요 없는 경우 JBoss EAP에서 자동으로 true 로 설정합니다.

http-upgrade-endpoint

http- connector가 연결할 서버 측의 http- acceptor 를 지정합니다. 커넥터는 HTTP를 통해 멀티플렉싱되며 HTTP 업그레이드 후 관련 http-acceptor를 찾으려면 이 정보가 필요합니다. 이 속성은 http-connector 를 생성하고 관리자가 필요 없는 경우 JBoss EAP에서 자동으로 설정합니다.

local-address

http 또는 원격 커넥터의 경우 클라이언트가 원격 주소에 연결할 때 사용할 로컬 주소를 지정하는 데 사용됩니다. 로컬 주소를 지정하지 않으면 커넥터는 사용 가능한 모든 로컬 주소를 사용합니다.

local-port

http 또는 원격 커넥터의 경우 원격 주소에 연결할 때 클라이언트가 사용할 로컬 포트를 지정하는 데 사용됩니다. local-port 기본값(0)을 사용하면 커넥터를 통해 시스템에서 임시 포트를 선택할 수 있습니다. 유효한 포트 값은 0 에서 65535 입니다.

nio-remoting-threads

NIO를 사용하도록 구성된 경우 메시징은 기본적으로 들어오는 패킷을 처리하기 위해 Runtime.getRuntime().availableProcessors() 에서 보고한 코어 수(또는 하이퍼 스레드 수)의 3배에 해당하는 스레드 수를 사용합니다. 이 값을 재정의하려면 스레드 수에 대한 사용자 지정 값을 설정할 수 있습니다. 기본값은 -1 입니다.

tcp-no-delay

true 이면 Nagle의 알고리즘이 활성화됩니다. 이 알고리즘은 네트워크를 통해 전송되는 패킷 수를 줄여 TCP/IP 네트워크의 효율성을 향상시키는 데 도움이 됩니다. 기본값은 true입니다.

tcp-send-buffer-size

이 매개 변수는 TCP 전송 버퍼의 크기를 바이트로 결정합니다. 기본값은 32768 입니다.

tcp-receive-buffer-size

이 매개 변수는 TCP 수신 버퍼의 크기를 바이트로 결정합니다. 기본값은 32768 입니다.

use-nio-global-worker-pool

이 매개 변수는 자카르타 메시징 연결이 각 연결이 자체 풀을 보유하는 것이 아니라 단일 Java 스레드 풀을 공유하도록 합니다. 이렇게 하면 운영 체제에서 최대 프로세스 수가 소모되지 않도록 방지할 수 있습니다. 기본값은 true입니다.

8.5. 서버에 연결
링크 복사

클라이언트를 서버에 연결하려면 적절한 커넥터가 있어야 합니다. 이 작업을 수행하는 방법에는 두 가지가 있습니다. 서버에서 구성되고 JNDI 조회를 통해 가져올 수 있는 ConnectionFactory를 사용할 수 있습니다. 또는 ActiveMQ Artemis 핵심 API를 사용하고 클라이언트 측에서 전체 ConnectionFactory 를 구성할 수 있습니다.

8.5.1. 자카르타 메시징 연결 팩트
링크 복사

클라이언트는 JNDI를 사용하여 서버에 대한 연결을 제공하는 ConnectionFactory 개체를 조회할 수 있습니다. 연결 팩토리는 세 가지 유형의 커넥터를 각각 노출할 수 있습니다.

원격 연결기를 참조하는 연결 팩토리는 원격 클라이언트가 서버에서 메시지를 보내거나 받는 데 사용할 수 있습니다(connect-factory에 적절하게 내보낸 항목이 있다고 가정). remote-connector 는 connection - factory를 사용하여 클라이언트에 연결할 위치를 알려주는 socket- binding 과 연결됩니다.

in -vm-connector 를 참조하는 연결 팩토리는 로컬 클라이언트가 로컬 서버로 메시지를 보내거나 로컬 서버에서 메시지를 받는 데 적합합니다. in-vm-connector 는 여러 메시징 서버가 단일 JVM에서 실행될 수 있으므로 연결 할 connection-factory 를 사용하여 클라이언트에 알리는 server-id 와 연결됩니다.

http -connector 를 참조하는 연결 팩토리는 원격 클라이언트가 메시징 프로토콜로 업그레이드하기 전에 HTTP 포트에 연결하여 서버에서 메시지를 보내거나 받는 데 적합합니다. http-connector 는 HTTP 소켓을 나타내는 socket-binding 과 연결되며, 기본적으로 이름이 http 입니다.

Jakarta Messaging 2.0 이후 기본 Jakarta Messaging 연결 팩토리는 JNDI 이름 java:comp/DefaultJMSConnectionFactory 아래 Jakarta EE 애플리케이션에서 액세스할 수 있습니다. messaging-activemq 하위 시스템은 이 기본 연결 팩토리를 제공하는 데 사용되는 pooled-connection-factory 를 정의합니다.

다음은 JBoss EAP의 전체 구성 프로필에 포함된 기본 커넥터 및 연결 팩토리입니다. 

<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>
Copy to Clipboard Toggle word wrap

팩토리의 entries 특성은 팩토리가 노출될 JNDI 이름을 지정합니다. 원격 클라이언트에는 java:jboss/exported 네임스페이스에 바인딩된 JNDI 이름만 사용할 수 있습니다. connection-factory 에 java:jboss/exported 네임스페이스에 바인딩된 항목이 있는 경우 원격 클라이언트는 java:jboss/exported 다음에 텍스트를 사용하여 connection-factory 를 조회합니다. 예를 들어 RemoteConnectionFactory 는 기본적으로 java:jboss/exported/jms/RemoteConnectionFactory 에 바인딩됩니다. 즉 원격 클라이언트가 jms/RemoteConnectionFactory 를 사용하여 이 연결 팩토리를 조회합니다. pooled-connection-factory 는 원격 클라이언트에 적합하지 않기 때문에 java:jboss/exported 네임스페이스에 바인딩 된 항목이 없어야 합니다.

8.5.2. JNDI를 사용하여 서버에 연결
링크 복사

클라이언트가 서버와 동일한 JVM 내에 있는 경우 InVmConnectionFactory 에서 제공하는 in-vm 커넥터를 사용할 수 있습니다. 다음은 InvmConnectionFactory 를 구성하는 방법입니다(예: standalone-full.xml ). 

<connection-factory
  name="InVmConnectionFactory"
  entries="java:/ConnectionFactory"
  connectors="in-vm" />
Copy to Clipboard Toggle word wrap

entries 속성의 값을 확인합니다. 다음 예와 같이 InVmConnectionFactory 를 사용하는 클라이언트는 조회 중에 주요 java:/ 를 삭제해야 합니다. 

InitialContext ctx = new InitialContext();
ConnectionFactory cf = (ConnectionFactory)ctx.lookup("ConnectionFactory");
Connection connection = cf.createConnection();
Copy to Clipboard Toggle word wrap

원격 클라이언트는 일반적으로 아래와 같이 구성된 RemoteConnectionFactory 를 사용합니다. 

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

원격 클라이언트는 아래의 코드 조각 예제에 따라 항목 값의 선행 java:jboss/exported/ 를 무시해야 합니다. 

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");
Copy to Clipboard Toggle word wrap

PROVIDER_URL 속성의 값과 클라이언트가 JBoss EAP http-remoting 프로토콜을 사용하는 방법을 확인합니다. 클라이언트가 org.wildfly.naming.client.WildFlyInitialContextFactory 를 사용하는 방법도 참조하십시오. 이는 클라이언트가 클래스에 있는 클라이언트 JAR을 포함하는 것입니다. maven 프로젝트의 경우 다음 종속성을 포함하여 이 작업을 수행할 수 있습니다. 

<dependencies>
  <dependency>
    <groupId>org.wildfly</groupId>
    <artifactId>wildfly-jms-client-bom</artifactId>
    <type>pom</type>
  </dependency>
</dependencies>
Copy to Clipboard Toggle word wrap

8.5.3. 코어 API를 사용하여 서버에 연결
링크 복사

Core API를 사용하여 JNDI 조회 없이도 클라이언트 연결을 만들 수 있습니다. Core API를 사용하는 클라이언트에는 JNDI 기반 클라이언트와 마찬가지로 클래스 경로에 클라이언트 JAR이 필요합니다.

ServerLocator

클라이언트는 ServerLocator 인스턴스를 사용하여 ClientSessionFactory 인스턴스를 생성합니다. 이름에서 알 수 있듯이 ServerLocator 인스턴스는 서버를 찾고 연결을 생성하는 데 사용됩니다.

자카르타 메시징 용어에서는 자카르타 메시징 연결 팩토리와 동일한 방식으로 ServerLocator 를 생각하십시오.

ServerLocator 인스턴스는 ActiveMQClient 팩토리 클래스를 사용하여 생성됩니다. 

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(new TransportConfiguration(InVMConnectorFactory.class.getName()));
Copy to Clipboard Toggle word wrap
ClientSessionFactory

클라이언트는 ClientSessionFactory 를 사용하여 기본적으로 서버 연결인 ClientSession 인스턴스를 생성합니다. 자카르타 메시징 용어에서는 이를 자카르타 메시징 연결로 간주합니다.

ClientSessionFactory 인스턴스는 ServerLocator 클래스를 사용하여 생성됩니다. 

ClientSessionFactory factory =  locator.createClientSessionFactory();
Copy to Clipboard Toggle word wrap
ClientSession

클라이언트는 메시지를 사용하고 생성하고 트랜잭션에 그룹화하기 위해 ClientSession 을 사용합니다. ClientSession 인스턴스는 트랜잭션 및 비 트랜잭션 의미 체계를 모두 지원할 수 있으며, 메시지 작업을 자카르타 트랜잭션 작업의 일부로 수행할 수 있도록 XAResource 인터페이스를 제공할 수도 있습니다.

ClientSession 인스턴스 그룹 ClientConsumers 및 ClientProducers. 

ClientSession session = factory.createSession();
Copy to Clipboard Toggle word wrap

아래 간단한 예는 방금 설명한 몇 가지를 강조합니다. 

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();
Copy to Clipboard Toggle word wrap

8.6. 로드 밸런서를 통한 메시징
링크 복사

JBoss EAP를 로드 밸런서 장치로 사용하는 경우 클라이언트는 정적 Undertow HTTP 로드 밸런서 또는 mod_cluster 로드 밸런서 뒤의 메시징 서버를 호출할 수 있습니다.

정적 로드 밸런서를 통해 메시징 서버를 호출하는 메시징 클라이언트를 지원하는 구성은 다음 요구 사항을 충족해야 합니다.

  • JBoss EAP를 로드 밸런서 장치로 사용하는 경우 HTTP 또는 HTTPS를 사용하여 로드 밸런서를 구성해야 합니다. 메시징 로드 밸런서에는 AJP가 지원되지 않습니다.

  • 로드 밸런서 뒤에 있는 메시징 서버에서 JNDI 조회가 발생하는 경우 백엔드 메시징 작업자를 구성해야 합니다.
  • 로드 밸런서 장치에 연결된 클라이언트는 동일한 서버와 통신하기 위해 로드 밸런서 장치에 대한 초기 연결을 재사용해야 합니다. 로드 밸런서에 연결하는 클라이언트는 클러스터 토폴로지를 사용하여 로드 밸런서에 연결해서는 안 됩니다. 클러스터 토폴로지를 사용하면 메시지가 다른 서버로 전송되어 트랜잭션 처리가 중단될 수 있습니다.

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)
Copy to Clipboard Toggle word wrap
백엔드 작업자 구성

로드 밸런서 백그라운드에서 JNDI 조회를 수행하려는 경우에만 백엔드 메시징 작업자를 구성해야 합니다.

  1. 로드 밸런싱 서버를 가리키는 새 아웃바운드 소켓 바인딩을 만듭니다. 

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=balancer-binding:add(host=load_balance.example.com,port=8080)
    Copy to Clipboard Toggle word wrap

  2. 로드 밸런싱 서버 소켓 바인딩을 참조하는 HTTP 커넥터를 생성합니다. 

    /subsystem=messaging-activemq/server=default/http-connector=balancer-connector:add(socket-binding=balancer-binding, endpoint=http-acceptor)
    Copy to Clipboard Toggle word wrap

  3. HTTP 커넥터를 클라이언트에서 사용하는 연결 팩토리에 추가합니다. 

    /subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=connectors,value=[balancer-connector])
    Copy to Clipboard Toggle word wrap

    초기 연결을 다시 사용하도록 클라이언트를 구성해야 합니다. 

    /subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=use-topology-for-load-balancing,value=false)
    Copy to Clipboard Toggle word wrap

9장. 연결 팩트 구성
링크 복사

기본적으로 JBoss EAP messaging-activemq 하위 시스템은 InVmConnectionFactory 및 RemoteConnectionFactory 연결 팩토리 와 a activemq-ra 풀링된 연결 팩토리를 제공합니다.

기본 연결 정보

InVmConnectionFactory 는 in-vm-connector 를 참조하며 클라이언트와 서버가 동일한 JVM에서 모두 실행 중인 경우 메시지를 보내고 받는 데 사용할 수 있습니다. RemoteConnectionFactory 는 http-connector 를 참조하며 클라이언트와 서버가 다른 JVM에서 실행될 때 HTTP를 통해 메시지를 보내고 받는 데 사용할 수 있습니다. 

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
    <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
    ...
  </server>
</subsystem>
Copy to Clipboard Toggle word wrap

다양한 유형의 커넥터에 대한 자세한 내용은 Acceptors 및 Connectors 섹션을 참조하십시오.

연결 팩토리 추가

다음 관리 CLI 명령을 사용하여 새 연결 팩토리를 추가할 수 있습니다. 연결 팩토리를 추가할 때 커넥터 및 JNDI 항목을 제공해야 합니다. 

/subsystem=messaging-activemq/server=default/connection-factory=MyConnectionFactory:add(entries=[java:/MyConnectionFactory],connectors=[in-vm])
Copy to Clipboard Toggle word wrap
연결 팩토리 구성

관리 CLI를 사용하여 연결 팩토리의 설정을 업데이트할 수 있습니다. 

/subsystem=messaging-activemq/server=default/connection-factory=MyConnectionFactory:write-attribute(name=thread-pool-max-size,value=40)
Copy to Clipboard Toggle word wrap

연결 팩토리에 사용 가능한 속성에 대한 자세한 내용은 연결 팩토리 속성 에서 참조하십시오.

연결 팩토리 제거

관리 CLI를 사용하여 연결 팩토리를 제거할 수 있습니다. 

/subsystem=messaging-activemq/server=default/connection-factory=MyConnectionFactory:remove
Copy to Clipboard Toggle word wrap

풀링된 연결 팩트

JBoss EAP messaging-activemq 하위 시스템은 통합된 ActiveMQ Artemis 리소스 어댑터의 인바운드 및 아웃바운드 커넥터를 구성할 수 있는 풀링된 연결 팩토리를 제공합니다. 원격 ActiveMQ Artemis 서버에 연결하기 위해 pooled-connection-factory 구성에 대한 자세한 내용은 원격 연결을 위한 통합 리소스 어댑터 사용을 참조하십시오. 

<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>
Copy to Clipboard Toggle word wrap

풀링된 연결 팩토리의 몇 가지 고유한 특성이 있습니다.

  • 원격 서버를 가리키도록 구성할 수 있지만 로컬 클라이언트만 사용할 수 있습니다. 원격 ActiveMQ Artemis 서버에 연결하는 방법에 대한 자세한 내용은 원격 연결을 위한 Integrated Artemis Resource Adapter 사용을 참조하십시오.
  • JNDI로 조회되거나 삽입된 경우에만 메시지를 전송하는 데 사용해야 합니다.
  • 보안 자격 증명을 사용하도록 구성할 수 있습니다. 보안 자격 증명이 보안 원격 서버를 가리키는 경우 유용합니다.
  • 이를 통해 획득한 리소스는 지속적인 자카르타 트랜잭션에 자동으로 등록됩니다.
풀링된 연결 팩토리 추가

다음 관리 CLI 명령을 사용하여 풀링된 새 연결 팩토리를 추가할 수 있습니다. 연결 팩토리를 추가할 때 커넥터 및 JNDI 항목을 제공해야 합니다. 

/subsystem=messaging-activemq/server=default/pooled-connection-factory=MyPooledConnectionFactory:add(entries=[java:/MyPooledConnectionFactory],connectors=[in-vm])
Copy to Clipboard Toggle word wrap
풀링된 연결 팩토리 구성

관리 CLI를 사용하여 풀링된 연결 팩토리의 설정을 업데이트할 수 있습니다. 

/subsystem=messaging-activemq/server=default/pooled-connection-factory=MyPooledConnectionFactory:write-attribute(name=max-retry-interval,value=3000)
Copy to Clipboard Toggle word wrap

풀링된 연결 팩토리의 사용 가능한 속성에 대한 자세한 내용은 Pooled Connection factory Attributes 를 참조하십시오.

enlist ment-trace 특성을 false 로 설정하여 관리 CLI를 사용하여 이 풀링된 연결 팩토리의 등록 추적 기록을 비활성화할 수 있습니다. 

/subsystem=messaging-activemq/server=default/pooled-connection-factory=MyPooledConnectionFactory:write-attribute(name=enlistment-trace,value=false)
Copy to Clipboard Toggle word wrap
주의

인리스트 추적을 비활성화하면 트랜잭션 입력 중에 오류가 중단됩니다.

풀링된 연결 팩토리에서 사용하는 관리형 연결 풀 구현을 구성할 수도 있습니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리형 연결 풀 구성 섹션을 참조하십시오.

풀링된 연결 팩토리 제거

관리 CLI를 사용하여 풀링된 연결 팩토리를 제거할 수 있습니다. 

/subsystem=messaging-activemq/server=default/pooled-connection-factory=MyPooledConnectionFactory:remove
Copy to Clipboard Toggle word wrap

10장. 지속성 구성
링크 복사

10.1. JBoss EAP 7 Messaging의 지속성 정보
링크 복사

JBoss EAP에는 바인딩 데이터 및 메시지를 저장하기 위한 두 가지 지속성 옵션이 포함되어 있습니다.

  • 메시징 사용 사례에 최적화되어 뛰어난 성능을 제공하는 기본 파일 기반 저널을 사용할 수 있습니다. 이 옵션은 기본적으로 제공되며 추가 구성을 수행하지 않는 경우 사용됩니다.
  • JDBC를 사용하여 선택한 데이터베이스에 연결하는 JDBC 데이터 저장소에 데이터를 저장할 수 있습니다. 이 옵션을 사용하려면 서버 구성 파일에 데이터 소스 및 messaging-activemq 하위 시스템을 구성해야 합니다.

10.2. 기본 파일 저널을 사용한 메시징 저널 지속성
링크 복사

JBoss EAP 메시징에는 메시징에 최적화된 고성능 파일 기반 저널이 포함되어 있습니다.

JBoss EAP 메시징 저널에는 구성 가능한 파일 크기가 있으며 추가만 추가되므로 단일 쓰기 작업을 활성화하여 성능이 향상됩니다. 디스크의 파일 집합으로 구성되며 처음에는 고정된 크기로 미리 만들어 패딩으로 채워집니다. add message, delete message, update message 등의 서버 작업이 수행되면 다음 저널 파일이 사용되는 저널 파일이 가득 찰 때까지 작업의 레코드가 저널에 추가됩니다.

정교한 가비지 컬렉션 알고리즘은 모든 데이터가 삭제될 때 저널 파일을 회수하고 다시 사용할 수 있는지 여부를 결정합니다. 압축 알고리즘은 저널 파일에서 잘못된 공간을 제거하고 데이터를 압축합니다.

저널은 로컬 및 XA 트랜잭션을 모두 완벽하게 지원합니다.

10.2.1. 메시징 저널 파일 시스템 구현
링크 복사

대부분의 저널은 Java로 작성되지만 다양한 플러그형 구현을 허용하도록 파일 시스템과의 상호 작용이 추상화되었습니다. JBoss EAP 메시징과 함께 제공되는 두 가지 구현은 다음과 같습니다.

Java New I/O(NIO)
이 구현에서는 표준 Java NIO를 사용하여 파일 시스템과 상호 작용합니다. 매우 우수한 성능을 제공하며 Java 6 이상 런타임이 포함된 모든 플랫폼에서 실행됩니다. JBoss EAP 7에는 Java 8이 필요합니다. NIO 사용은 JBoss EAP가 지원하는 모든 운영 체제에서 지원됩니다.
Linux 비동기 IO(ASYNCIO)

이 구현에서는 기본 코드 래퍼를 사용하여 Linux 비동기 IO 라이브러리(ASYNCIO)와 통신합니다. 이 구현에서는 명시적 동기화가 필요하지 않습니다. 일반적으로 ASYNCIO는 Java NIO보다 우수한 성능을 제공합니다.

사용 중인 저널 유형을 확인하려면 다음 CLI 요청을 실행합니다. 

/subsystem=messaging-activemq/server=default:read-attribute(name=runtime-journal-type)
Copy to Clipboard Toggle word wrap

시스템에서 다음 값 중 하나를 반환합니다.

Expand
표 10.1. 저널 유형 반환 값
반환 값설명

NONE

지속성이 비활성화됨

NIO

Java NIO 사용 중

ASYNCIO

libaio 가 있는 ASYNCIO가 사용되고 있습니다

데이터베이스

JDBC 지속성이 사용 중입니다

다음 파일 시스템은 libaio 네이티브를 사용하는 경우 테스트되었으며 Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7 및 Red Hat Enterprise Linux 8에서만 지원됩니다. 테스트되지 않으며 다른 운영 체제에서는 지원되지 않습니다.

  • EXT4
  • XFS
  • NFSv4
  • GFS2

다음 표에는 libaio 네이티브가 있는지 여부와 테스트된 HA 공유 저장소 파일 시스템이 나열되어 있습니다.

Expand
운영 체제파일 시스템libaio Natives를 사용하여 지원됩니까?
(journal-type="ASYNCIO")		libaio Natives를 사용하지 않고 지원됩니까?
(journal-type="NIO")

Red Hat Enterprise Linux 6

NFSv4

있음

있음

Red Hat Enterprise Linux 7 이상

NFSv4

있음

있음

Red Hat Enterprise Linux 6

GFS2

있음

없음

Red Hat Enterprise Linux 7 이상

GFS2

있음

없음

10.2.2. 표준 메시징 저널 파일 시스템 인스턴스
링크 복사

표준 JBoss EAP 메시징 코어 서버는 다음 저널 인스턴스를 사용합니다.

바인딩 저널

이 저널은 서버 및 해당 속성에 배포된 큐 집합을 포함하여 바인딩 관련 데이터를 저장하는 데 사용됩니다. 또한 id 시퀀스 카운터와 같은 데이터를 저장합니다.

바인딩 저널은 일반적으로 메시지 저널에 비해 처리량이 낮기 때문에 NIO 저널입니다.

이 저널의 파일은 activemq-bindings로 접두사로 지정됩니다. 각 파일에는 바인딩 확장자가 있습니다. 파일 크기는 1048576이며 bindings 폴더에 있습니다.

자카르타 메시징 저널

이 저널 인스턴스는 자카르타 메시징 대기열, 토픽, 연결 팩토리 및 이러한 리소스에 대한 모든 JNDI 바인딩과 같은 모든 자카르타 메시징 관련 데이터를 저장합니다.

관리 API를 통해 생성된 자카르타 메시징 리소스는 이 저널에 저장됩니다. 구성 파일을 통해 구성된 모든 리소스는 그렇지 않습니다. 자카르타 메시징 저널은 Jakarta Messaging이 사용되는 경우에만 생성됩니다.

이 저널의 파일은 activemq-jms로 접두사로 지정됩니다. 각 파일에는 jms 확장자가 있습니다. 파일 크기는 1048576이며 bindings 폴더에 있습니다.

메시지 저널

이 저널 인스턴스는 메시지 자체와 중복 ID 캐시를 비롯한 모든 메시지 관련 데이터를 저장합니다.

기본적으로 JBoss EAP 메시징은 ASYNCIO 저널 사용을 시도합니다. ASYNCIO를 사용할 수 없는 경우 예를 들어 올바른 커널 버전이 있는 Linux가 아니거나 ASYNCIO가 설치되지 않은 경우 모든 Java 플랫폼에서 사용할 수 있는 Java NIO를 사용하는 것으로 자동 대체됩니다.

이 저널의 파일은 activemq-data 접두사로 지정됩니다. 각 파일에는 amq 확장자가 있습니다. 파일 크기는 기본적으로 10485760(설정 가능)이며 저널 폴더에 있습니다.

대규모 메시지의 경우 JBoss EAP 메시징은 메시지 저널 외부에 보관합니다. 이 내용은 Large Messages (대문자 메시지) 섹션에서 설명합니다.

JBoss EAP 메시징은 메시지를 메모리 부족 상태에서 디스크에 페이징하도록 구성할 수도 있습니다. 이에 대해서는 Paging(보내기) 섹션에서 설명합니다.

지속성이 전혀 필요하지 않은 경우 JBoss EAP 메시징은 JBoss EAP 메시징 구성 섹션에서 설명한 대로 스토리지에 전혀 데이터를 유지하지 않도록 구성할 수도 있습니다.

10.2.3. 바인딩 및 자카르타 메시징 저널 구성
링크 복사

바인딩 저널은 자카르타 메시징 저널과 구성을 공유하기 때문에 아래의 단일 관리 CLI 명령을 사용하여 둘 다의 현재 구성을 읽을 수 있습니다. 기본 구성을 강조 표시하기 위해 출력도 포함되어 있습니다. 

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

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

기본적으로 저널 is activemq/bindings 의 경로 는 다음과 같습니다. 다음 관리 CLI 명령을 사용하여 경로 의 위치를 변경할 수 있습니다. 

/subsystem=messaging-activemq/server=default/path=bindings-directory:write-attribute(name=path,value=PATH_LOCATION)
Copy to Clipboard Toggle word wrap

또한 위의 출력에서 relative-to 특성을 확인합니다. relative-to 를 사용하는 경우 경로 속성의 값은 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=bindings-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)
Copy to Clipboard Toggle word wrap

기본적으로 JBoss EAP는 바인딩 디렉터리가 없는 경우 자동으로 생성하도록 구성됩니다. 다음 관리 CLI 명령을 사용하여 이 동작을 전환합니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=create-bindings-dir,value=TRUE/FALSE)
Copy to Clipboard Toggle word wrap

값을 true 로 설정하면 자동 디렉터리 생성을 사용할 수 있습니다. 값을 false 로 설정하면 비활성화됩니다.

10.2.4. 메시지 저널 위치 구성
링크 복사

아래 관리 CLI 명령을 사용하여 메시지 저널의 위치 정보를 읽을 수 있습니다. 기본 구성을 강조 표시하기 위해 출력도 포함되어 있습니다. 

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

기본적으로 저널 is activemq/journal 의 경로 는 입니다. 다음 관리 CLI 명령을 사용하여 경로 의 위치를 변경할 수 있습니다. 

/subsystem=messaging-activemq/server=default/path=journal-directory:write-attribute(name=path,value=PATH_LOCATION)
Copy to Clipboard Toggle word wrap
참고

최상의 성능을 위해 Red Hat은 디스크 헤드 이동을 최소화하기 위해 저널을 자체 물리 볼륨에 있는 것이 좋습니다. 저널이 바인딩 저널, 데이터베이스 또는 트랜잭션 코디네이터와 같은 다른 파일을 작성할 수 있는 다른 프로세스와 공유되는 볼륨에 있는 경우 디스크 헤드가 작성 시 이러한 파일 간에 빠르게 이동되므로 성능이 크게 저하될 수 있습니다.

또한 위의 출력에서 relative-to 특성을 확인합니다. relative-to 를 사용하는 경우 경로 속성의 값은 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=journal-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)
Copy to Clipboard Toggle word wrap

기본적으로 저널 디렉터리가 없는 경우 저널 디렉터리를 자동으로 생성하도록 JBoss EAP를 구성합니다. 다음 관리 CLI 명령을 사용하여 이 동작을 전환합니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=create-journal-dir,value=TRUE/FALSE)
Copy to Clipboard Toggle word wrap

값을 true 로 설정하면 자동 디렉터리 생성을 사용할 수 있습니다. 값을 false 로 설정하면 비활성화됩니다.

10.2.5. 메시지 저널 속성 구성
링크 복사

아래에 열거된 속성은 메시징 서버의 모든 하위 속성입니다. 따라서 관리 CLI를 사용하여 값을 가져오고 설정하는 명령 구문은 각각 동일합니다.

주어진 속성의 현재 값을 읽으려면 구문은 다음과 같습니다. 

/subsystem=messaging-activemq/server=default:read-attribute(name=ATTRIBUTE_NAME)
Copy to Clipboard Toggle word wrap

속성 값을 작성하는 구문은 해당 패턴을 따릅니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=ATTRIBUTE_NAME,value=NEW_VALUE)
Copy to Clipboard Toggle word wrap

  • create-journal-dir

    이 값이 true 로 설정되면 저널 디렉터리가 아직 없는 경우 journal-directory 에 지정된 위치에 자동으로 생성됩니다. 기본값은 true입니다.

  • journal-file-open-timeout

    이 특성은 저널 파일을 여는 시간 초과 값을 수정합니다. 기본값은 5 초입니다.

  • journal-buffer-timeout

    플러시가 필요한 모든 쓰기에 플러시하는 대신 내부 버퍼를 유지 관리하고 전체 버퍼가 가득 찰 때 또는 시간 제한이 만료된 시점 중 어느 쪽이 더 빨리 만료되는지 확인합니다. 이는 NIO 및 ASYNCIO 모두에 사용되며 플러시가 필요한 많은 동시 쓰기로 시스템을 더 효율적으로 확장할 수 있습니다.

    이 매개변수는 아직 입력하지 않은 경우 버퍼가 플러시될 시간 초과를 제어합니다. ASYNCIO는 일반적으로 NIO보다 더 높은 플러시 속도를 처리할 수 있으므로 시스템은 NIO 및 ASYNCIO 모두에 대해 다른 기본값을 유지합니다. NIO의 기본값은 3 3333 나노 초 또는 초당 300번입니다. ASYNCIO의 기본값은 500000 나노초 또는 초당 2000 번입니다.

    참고

    시간 초과를 늘리면 대기 시간을 희생하여 시스템 처리량을 늘릴 수 있으며, 처리량과 대기 시간 간에 적절한 균형을 유지하기 위해 기본 매개 변수를 선택합니다.

  • journal-buffer-size

    ASYNCIO에서 시간 초과된 버퍼의 크기(바이트)입니다. journal-buffer-size 및 journal-file-size 는 모두 min-large-message-size 보다 크게 설정해야 합니다. 그렇지 않으면 메시지가 저널에 작성되지 않습니다. 자세한 내용은 큰 메시지 구성을 참조하십시오.

  • journal-compact-min-files

    저널 압축을 고려하기 전에 최소 파일 수입니다. 압축 알고리즘은 최소한 journal-compact-min-file이 있을 때까지 시작되지 않습니다.

    이 값을 0 으로 설정하면 기능이 완전히 압축되지 않습니다. 저널이 무기한 확장될 수 있기는 하지만 이는 위험할 수 있습니다. 현명하게 사용하십시오!

    이 매개변수의 기본값은 10입니다.

  • journal-compact-percentage

    압축을 시작할 임계값입니다. 이 백분율 미만이 실시간 데이터로 간주되면 압축을 시작합니다. 저널에 journal-compact-min-files 데이터 파일이 있을 때까지 압축이 시작되지 않습니다.

    이 매개변수의 기본값은 30 입니다.

  • journal-file-size

    각 저널 파일의 크기(바이트)입니다. 이 값의 기본값은 10485760바이트 또는 10MB입니다. journal-file-size 및 journal-buffer-size 는 모두 min-large-message-size 보다 크게 설정해야 합니다. 그렇지 않으면 메시지가 저널에 작성되지 않습니다. 자세한 내용은 큰 메시지 구성을 참조하십시오.

  • journal-max-io

    쓰기 요청은 실행을 위해 시스템에 제출되기 전에 대기합니다. 이 매개 변수는 언제든지 IO 큐에 있을 수 있는 최대 쓰기 요청 수를 제어합니다. 큐가 가득 차면 공간이 확보될 때까지 쓰기가 차단됩니다.

    시스템은 NIO 또는 ASYNCIO인지 여부에 따라 이 매개변수의 기본값이 서로 다릅니다. NIO의 기본값은 1 이고 ASYNCIO의 기본값은 500 입니다.

    제한이 있으며 총 최대 ASYNCIO는 OS 수준에서 구성된 것보다 클 수 없으며, /proc/sys/fs/aio-max-nr(일반적으로 65536 )에서 찾을 수 있습니다.

  • journal-min-files

    저널이 유지 관리할 최소 파일 수입니다. JBoss EAP가 시작되고 초기 메시지 데이터가 없으면 JBoss EAP는 journal-min-files 의 파일 수를 미리 생성합니다. 기본값은 2 입니다.

    저널 파일을 만들고 패딩을 채우는 것은 비용이 많이 드는 작업이며, 파일을 채우면서 런타임에 이 작업을 최소화하고자 합니다. 파일을 미리 만들면 저널이 작성되지 않고 즉시 다음 파일로 다시 시작할 수 있습니다.

    큐에 안정적인 상태로 포함될 것으로 예상되는 데이터 양에 따라 이 파일 수를 조정하여 총 데이터 양과 일치해야 합니다.

  • journal-pool-files

    재사용할 수 있는 저널 파일 수입니다. ActiveMQ는 필요한 만큼 많은 파일을 생성하지만 파일을 회수할 때 값으로 축소됩니다. 기본값은 -1 이며 제한이 없음을 의미합니다.

  • journal-sync-transactional

    true로 설정된 경우 JBoss EAP는 커밋, 준비 또는 롤백과 같은 트랜잭션 경계의 디스크로 모든 트랜잭션 데이터가 디스크로 플러시되도록 합니다. 기본값은 true입니다.

  • journal-sync-non-transactional

    이 값이 true로 설정되면 JBoss EAP는 전송 및 승인과 같은 트랜잭션이 아닌 메시지 데이터가 매번 디스크에 플러시되도록 합니다. 기본값은 true입니다.

  • journal-type

    유효한 값은 NIO 또는 ASYNCIO 입니다.

    NIO 를 선택하면 JBoss EAP에 Java NIO 저널을 사용하도록 지시합니다. ASYNCIO 는 Linux 비동기 IO 저널을 사용하도록 지시합니다. ASYNCIO 를 선택하지만 Linux가 실행 중이 아니거나 libaio가 설치되어 있지 않은 경우 JBoss EAP는 Java NIO 저널을 사용합니다.

10.2.6. 디스크 쓰기 캐시 비활성화 시 알림
링크 복사

운영 체제에서 fsync() 를 실행했는지 또는 Java 프로그램 내부에서 올바르게 동기화된 데이터를 실행했는지에 관계없이 발생합니다!

기본적으로 많은 시스템은 디스크 쓰기 캐시가 활성화된 상태로 제공됩니다. 즉, 운영 체제와 동기화한 후에도 데이터가 디스크에 실제로 수행된다는 보장이 없으므로 오류가 발생하면 중요한 데이터가 손실될 수 있습니다.

일부 고가의 디스크에는 휘발성 또는 배터리 지원 쓰기 캐시가 있어 장애 발생 시 데이터가 손실되지 않지만 테스트해야 합니다!

디스크에 휘발성 또는 배터리가 많이 지원되는 캐시가 없고 RAID와 같은 중복 배열의 일부가 아니며 데이터 무결성을 평가하여 디스크 쓰기 캐시가 비활성화되었는지 확인합니다.

디스크 쓰기 캐시를 비활성화하면 성능이 저하될 수 있습니다. 기본 설정에서 쓰기 캐시가 활성화된 디스크를 사용하는 경우 데이터 무결성이 손상될 수 있다는 것을 인식하지 못하면 비활성화하면 안정적으로 작업할 때 디스크가 얼마나 빠르게 작동하는지에 대한 아이디어가 제공됩니다.

Linux에서는 IDE 디스크의 경우 toolparm, SDSI/SATA 디스크의 경우 sd parm 또는 sginfo 를 사용하여 디스크 쓰기 캐시 설정을 검사하거나 변경할 수 있습니다.

Windows에서는 디스크를 마우스 오른쪽 버튼으로 클릭한 다음 속성을 클릭하여 설정을 확인하고 변경할 수 있습니다.

10.2.7. libaio 설치
링크 복사

Java NIO 저널은 성능이 뛰어나지만 Linux 커널 2.6 이상을 사용하여 JBoss EAP 메시징을 실행하는 경우 Red Hat은 최상의 지속성 성능을 위해 ASYNCIO 저널을 사용하는 것이 좋습니다.

참고

JBoss EAP는 Red Hat Enterprise Linux 버전 6, 7 또는 8에 설치하고 ext4, xfs, gfs2 또는 nfs4 파일 시스템을 사용하는 경우에만 ASYNCIO를 지원합니다. 다른 운영 체제 또는 이전 버전의 Linux 커널에서는 ASYNCIO 저널을 사용할 수 없습니다.

ASYNCIO 저널을 사용하려면 libaio 가 설치되어 있어야 합니다. 설치하려면 다음 명령을 사용합니다.

  • Red Hat Enterprise Linux 6 및 7의 경우: 

    yum install libaio
    Copy to Clipboard Toggle word wrap

  • Red Hat Enterprise Linux 8의 경우: 

    dnf install libaio
    Copy to Clipboard Toggle word wrap
주의

예를 들어 /tmp 디렉토리에 사용되는 tmpfs 파일 시스템에 메시징 저널을 배치하지 마십시오. ASYNCIO 저널이 tmpfs를 사용하는 경우 JBoss EAP가 시작되지 않습니다.

10.2.8. 메시징을 위한 NFS 공유 저장소 구성
링크 복사

데이터 복제를 위한 전용 공유 저장소, 고가용성을 사용하는 경우 NFS 클라이언트에서 공유 디렉터리를 사용하도록 라이브 서버와 백업 서버를 모두 구성해야 합니다. NFS 서버에서 공유 디렉터리를 사용하도록 하나의 서버를 구성하고 다른 서버가 NFS 클라이언트에서 공유 디렉터리를 사용하도록 구성하는 경우, 백업 서버는 라이브 서버가 시작되거나 실행 중인 시점을 인식할 수 없습니다. 따라서 제대로 작동하려면 두 서버 모두 NFS 클라이언트에 공유 디렉터리를 지정해야 합니다.

또한 NFS 클라이언트 마운트에 대해 다음 옵션을 구성해야 합니다.

  • sync: 이 옵션은 모든 변경 사항이 즉시 디스크로 플러시되도록 지정합니다.
  • intr: 이 옵션을 사용하면 서버가 다운되거나 연결할 수 없는 경우 NFS 요청이 중단될 수 있습니다.
  • noac: 이 옵션은 특성 캐싱을 비활성화하고 여러 클라이언트 간에 속성 캐시 일관성을 달성하는 데 필요합니다.
  • soft: 이 옵션은 내보낸 파일 시스템을 제공하는 호스트를 사용할 수 없는 경우 서버가 다시 온라인 상태가 될 때까지 기다리지 않고 오류를 보고하도록 지정합니다.
  • lookupcache=none: 이 옵션은 조회 캐싱을 비활성화합니다.
  • timeo=n: NFS 클라이언트에서 NFS 요청을 재시도하기 전에 대기하는 시간(초의 10분의 1초)입니다. TCP를 통한 NFS의 경우 기본 timeo 값은 600 (60초)입니다. UDP를 통한 NFS의 경우 클라이언트는 적응형 알고리즘을 사용하여 읽기 및 쓰기 요청과 같이 자주 사용되는 요청 유형에 대한 적절한 시간 초과 값을 추정합니다.
  • retrans=n: NFS 클라이언트가 추가 복구 조치를 시도하기 전에 요청을 다시 시도하는 횟수입니다. retrans 옵션을 지정하지 않으면 NFS 클라이언트가 각 요청을 세 번 시도합니다.
중요

timeo 및 retrans 옵션을 구성할 때 합리적인 값을 사용하는 것이 중요합니다. 5 번 재시도 값과 결합된 600 디시초(60초)의 기본 대기 시간으로 인해 ActiveMQ Artemis가 NFS 연결이 탐지될 때까지 5분 동안 기다릴 수 있습니다.

고가용성을 위해 공유 파일 시스템을 사용하는 방법에 대한 자세한 내용은 이 가이드의 공유 저장소 섹션을 참조하십시오.

10.3. JDBC 데이터베이스를 사용한 메시징 저널 지속성
링크 복사

기본 파일 기반 저널을 사용하는 대신 메시지 및 바인딩 데이터를 데이터베이스에 바인딩하도록 JDBC를 사용하려면 JBoss EAP 7 메시징을 구성해야 합니다.

이렇게 하려면 먼저 데이터 소스 하위 시스템에서 datasource 요소를 구성한 다음 해당 데이터 소스를 사용하도록 messaging -activemq 하위 시스템의 server 요소에 journal- datasource 속성을 정의해야 합니다. journal-datasource 특성이 있으면 메시징 하위 시스템에서 파일 기반 저널 대신 데이터베이스에 저널 항목을 지속하도록 알립니다. messaging-tekton 하위 시스템의 서버 리소스에 대한 journal- database 속성은 데이터베이스와 통신하는 데 사용되는 SQL languageect를 정의합니다. 이 속성은 데이터 소스 메타데이터를 사용하여 자동으로 구성됩니다.

파일 기반 저널에 메시지를 유지하는 경우 큰 메시지 크기는 디스크 크기만으로 제한됩니다. 그러나 메시지를 데이터베이스에 보관할 때 큰 메시지 크기는 해당 데이터베이스에 대한 BLOB 데이터 유형의 최대 크기로 제한됩니다.

중요

JBoss EAP 7.4는 현재 Oracle 12c 및 IBM DB2 Enterprise 데이터베이스만 지원합니다.

10.3.1. 데이터베이스 영구 저장소 구성 고려 사항
링크 복사

안정성 향상을 위해 JBoss EAP는 연결 풀을 통해 메시징 호출을 수행하므로 여러 애플리케이션에서 공유할 수 있는 지정된 데이터베이스에 대한 열린 연결 세트를 제공합니다. 즉, JBoss EAP가 연결을 떨어지면 풀의 다른 연결은 실패를 방지하기 위해 실패한 연결을 대체합니다.

참고

이전 버전의 JBoss EAP는 풀에서 하나의 연결만 지원합니다.

데이터 소스 하위 시스템에서 데이터베이스 영구 저장소 또는 풀을 구성하는 경우 다음 포인트를 고려하십시오.

  • min-pool-size 특성 값을 최소 4개로 설정하여 다음 사용 시 각각에 대한 연결을 전용으로 지정합니다.

    • 바인딩된 경우One for the binding
    • 메시지 저널에 대한 1개
    • High Availability (HA)를 사용하는 경우 리스 잠금을 위한 것입니다.
    • HA를 사용하는 경우 노드 관리자 공유 상태용 1개
  • 페이징 또는 대용량 메시지 스트리밍 작업을 수행하는 동시 스레드 수에 따라 max-pool-size 속성 값을 설정합니다. 스레드 수와 연결 수가 일대일이 아니므로 max-pool-size 특성을 구성하기 위한 규칙이 정의되지 않습니다.

연결 수는 페이징 및 대용량 메시지 작업을 처리하는 스레드 수와 연결을 받기 위한 대기 시간을 정의하는 attribute blocking-timeout-wait-밀리코어is 에 따라 달라집니다.

새로운 큰 메시지 또는 페이징 작업이 전용 스레드에서 발생하며 연결이 필요합니다. 이러한 전용 스레드는 연결이 준비되거나 연결을 가져올 시간이 없어 오류가 발생할 때까지 큐에 추가됩니다.

요구 사항에 따라 풀 구성을 사용자 지정하고 해당 환경에서 구성된 풀을 테스트할 수 있습니다.

10.3.2. 메시징 저널 JDBC 지속성 저장소 구성
링크 복사

다음 단계에 따라 JDBC를 사용하여 메시지를 유지하고 데이터를 데이터베이스에 바인딩하도록 JBoss EAP 7 메시징을 구성합니다.

  1. messaging- tekton 하위 시스템에서 사용할 데이터 소스 하위 시스템에서 데이터 소스를 구성합니다. 데이터 소스를 생성하고 구성하는 방법에 대한 자세한 내용은 JBoss EAP 구성 가이드의 데이터 소스 관리를 참조하십시오.

  2. 새 데이터 소스를 사용하도록 messaging-activemq 하위 시스템을 구성합니다. 

    /subsystem=messaging-activemq/server=default:write-attribute(name=journal-datasource,value="MessagingOracle12cDS")
    Copy to Clipboard Toggle word wrap

    이렇게 하면 서버 구성 파일의 messaging-tekton 하위 시스템에 다음 구성이 생성됩니다. 

    <server name="default">
  <journal datasource="MessagingOracle12cDS"/>
  ...
</server>
    Copy to Clipboard Toggle word wrap

JBoss EAP 메시징은 이제 데이터베이스를 사용하여 메시징 데이터를 저장하도록 구성되어 있습니다.

10.3.3. 메시징 저널 테이블 이름 구성
링크 복사

JBoss EAP 7 메시징은 별도의 JDBC 테이블을 사용하여 바인딩 정보, 메시지, 대용량 메시지 및 페이징 정보를 저장합니다. 이러한 테이블의 이름은 서버 구성 파일의 messaging -activemq 하위 시스템에서 journal -bindings-table,journal-jms - bindings-table, journal-messages -table, journal-page-store- table 특성을 사용하여 구성할 수 있습니다.

다음은 테이블 이름 제한 목록입니다.

  • JBoss EAP 7 메시징은 GENERATED _ ID가 최대 20자까지 될 수 있는 패턴 TABLE_NAME + GENERATED _ID 를 사용하여 페이징 테이블의 식별자를 생성합니다. Oracle Database 12c의 최대 테이블 이름 길이는 30자이므로 테이블 이름을 10자로 제한해야 합니다. 그렇지 않으면 ORA-00972: 식별자가 너무 길고 페이징이 더 이상 작동하지 않습니다.
  • Oracle Database 12c에 대한 스키마 오브젝트 명명 규칙을 따르지 않는 테이블 이름은 큰따옴표로 묶어야 합니다. 따옴표로 묶은 식별자는 모든 문자로 시작할 수 있으며 문자와 문장 부호는 물론 공백을 포함할 수 있습니다. 그러나 따옴표로 묶거나 따옴표가 없는 식별자는 겹따옴표나 null 문자(\0)를 포함할 수 없습니다. 따옴표로 묶은 식별자는 대소문자를 구분하는 것이 중요합니다.
  • 여러 JBoss EAP 서버 인스턴스에서 동일한 데이터베이스를 사용하여 메시지 및 바인딩 데이터를 유지하는 경우 테이블 이름은 각 서버 인스턴스에 대해 고유해야 합니다. 여러 JBoss EAP 서버는 동일한 테이블에 액세스할 수 없습니다.

다음은 인용된 식별자를 사용하여 journal-page-store-table 이름을 구성하는 관리 CLI 명령의 예입니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-page-store-table,value="\"PAGE_DATA\"")
Copy to Clipboard Toggle word wrap

이렇게 하면 서버 구성 파일의 messaging-tekton 하위 시스템에 다음 구성이 생성됩니다. 

<server name="default">
  <journal datasource="MessagingOracle12cDS" journal-page-store-table="&quot;PAGED_DATA&quot;"/>
  ...
</server>
Copy to Clipboard Toggle word wrap

10.3.4. 관리형 도메인에서 메시징 저널 구성
링크 복사

메시징 저널 테이블 이름 구성에서 설명한 대로 JDBC를 사용하여 메시지를 유지하고 데이터를 데이터베이스에 바인딩할 때 여러 JBoss EAP 서버가 동일한 데이터베이스 테이블에 액세스할 수 없습니다. 관리형 도메인에서 서버 그룹의 모든 JBoss EAP 서버 인스턴스는 동일한 프로필 구성을 공유하므로 표현식을 사용하여 메시징 저널 이름 또는 데이터 소스를 구성해야 합니다.

모든 서버가 동일한 데이터베이스를 사용하여 메시징 데이터를 저장하도록 구성된 경우 테이블 이름은 각 서버 인스턴스에 고유해야 합니다. 다음은 이름의 고유한 노드 식별자를 포함하는 표현식을 사용하여 서버 그룹의 각 서버에 대해 고유한 journal-page-store-table 테이블 이름을 생성하는 관리 CLI 명령의 예입니다. 

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

각 서버 인스턴스가 다른 데이터베이스에 액세스하는 경우 표현식을 사용하여 각 서버의 메시징 구성이 다른 데이터 소스에 연결할 수 있습니다. 다음 관리 CLI 명령은 connection-url 에서 DB_CONNECTION_URL 환경 변수를 사용하여 다른 데이터 소스에 연결합니다. 

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

10.3.5. 메시징 저널 네트워크 시간 제한 구성
링크 복사

JDBC 연결에서 요청에 응답할 때까지 대기하는 최대 시간(밀리초)을 구성할 수 있습니다. 이는 네트워크가 중단되거나 JBoss EAP 메시징과 데이터베이스 간의 연결이 중단되는 경우 어떤 이유로든 데이터베이스가 닫힙니다. 이 경우 시간 초과가 발생할 때까지 클라이언트가 차단됩니다.

journal-jdbc-network-timeout 특성을 업데이트하여 시간 초과를 구성합니다. 기본값은 20000 밀리초 또는 20 초입니다.

다음은 journal-jdbc-network-timeout 속성 값을 10000 밀리초 또는 10 초로 설정하는 관리 CLI 명령의 예입니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-jdbc-network-timeout,value=10000)
Copy to Clipboard Toggle word wrap

10.3.6. 메시징 JDBC 지속성 스토어를 위한 HA 구성
링크 복사

JBoss EAP messaging-activemq 하위 시스템은 브로커가 데이터베이스 저장소 유형으로 구성된 경우 JDBC HA 공유 저장소 기능을 활성화합니다. 그런 다음 브로커는 공유 데이터베이스 테이블을 사용하여 라이브 및 백업 서버가 공유 JDBC 저널 저장소를 통해 작업을 조정하는지 확인합니다.

다음 특성을 사용하여 JDBC 지속성 저장소의 HA를 구성할 수 있습니다.

  • journal-node-manager-store-table: 노드 관리자를 저장할 JDBC 데이터베이스 테이블의 이름입니다.
  • journal-jdbc-lock-expiration: JDBC 잠금을 활성 상태로 유지하지 않고 유효한 것으로 간주되는 시간입니다. 이 특성 값을 초 단위로 지정합니다. 기본값은 20 초입니다.
  • journal-jdbc-lock-renew-period: JDBC 잠금의 유지 서비스 기간. 이 특성 값을 초 단위로 지정합니다. 기본값은 2 초입니다.

기본값은 서버의 ha-policy 및 journal- datasource 특성 값에 따라 고려됩니다.

이전 버전과의 호환성을 위해 각각의 Artemis 특정 시스템 속성을 사용하여 값을 지정할 수도 있습니다.

  • brokerconfig.storeConfiguration.nodeManagerStoreTableName
  • brokerconfig.storeConfiguration.jdbcLockExpirationMillis
  • brokerconfig.storeConfiguration.jdbcLockRenewPeriodMillis

설정 시 이러한tekton별 시스템 속성이 해당 속성의 기본값보다 우선합니다.

10.4. 메시징 저널 준비 트랜잭션 관리
링크 복사

다음 관리 CLI 명령을 사용하여 메시징 저널 준비 트랜잭션을 관리할 수 있습니다.

  • 준비된 트랜잭션을 커밋합니다. 

    /subsystem=messaging-activemq/server=default:commit-prepared-transaction(transaction-as-base-64=XID)
    Copy to Clipboard Toggle word wrap

  • 준비된 트랜잭션을 롤백합니다. 

    /subsystem=messaging-activemq/server=default:rollback-prepared-transaction(transaction-as-base-64=XID)
    Copy to Clipboard Toggle word wrap

  • 준비된 모든 트랜잭션의 세부 정보를 표시합니다. 

    /subsystem=messaging-activemq/server=default:list-prepared-transactions
    Copy to Clipboard Toggle word wrap
    참고

    list-prepared-transaction-details-as- html 작업을 사용하거나 list-prepared-transaction-details- details-as- json 작업을 사용하여 JSON 형식으로 준비된 트랜잭션 세부 정보를 HTML 형식으로 표시할 수도 있습니다.

10.5. 제로 지속성을 위한 JBoss EAP Messaging 구성
링크 복사

메시징 시스템에 제로 지속성이 필요한 경우도 있습니다. 제로 지속성은 데이터, 메시지 데이터, 대용량 메시지 데이터, 중복된 id 캐시 또는 페이징 데이터를 유지해야 함을 의미합니다.

지속성 0을 수행하도록 messaging-activemq 하위 시스템을 구성하려면 persistence-enabled 매개 변수를 false로 설정합니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=persistence-enabled,value=false)
Copy to Clipboard Toggle word wrap
중요

지속성이 비활성화되었지만 페이징이 활성화된 경우 페이지 파일은 paging -directory 요소에서 지정한 위치에 계속 저장됩니다. address-full-policy 특성이 PAGE 로 설정된 경우 페이징이 활성화됩니다. 전체 제로 지속성이 필요한 경우 BLOCK,DROP 또는 FAIL 을 사용하도록 address- setting 요소의 address- full-policy 특성을 구성해야 합니다.

10.6. 저널 데이터 가져오기 및 내보내기
링크 복사

저널 데이터 가져오기 및 내보내기에 대한 정보는 JBoss EAP 7 마이그레이션 가이드를 참조하십시오.

11장. 페이징 구성
링크 복사

11.1. 페이징 정보
링크 복사

JBoss EAP 메시징은 수백만 개의 메시지를 포함하는 각 대기열에서 많은 메시지 대기열을 지원합니다. JBoss EAP 메시징 서버는 제한된 메모리로 실행되므로 모든 메시지 큐를 한 번에 메모리에 저장하기가 어렵습니다.

페이징은 제한된 메모리에 대용량 메시지 큐를 수용하기 위해 필요에 따라 메모리 내/외부로 메시지를 투명하게 페이지 아웃하도록 JBoss EAP 메시징 서버에서 사용하는 메커니즘입니다.

JBoss EAP 메시징은 특정 주소에 대한 메모리의 메시지 크기가 구성된 최대 메시지 크기를 초과할 때 디스크에 페이징 메시지를 시작합니다.

참고

JBoss EAP 메시징 페이징은 기본적으로 활성화되어 있습니다.

11.2. 페이지 파일
링크 복사

여러 파일에 메시지를 저장하는 파일 시스템의 각 주소에 대한 개별 폴더가 있습니다. 메시지를 저장하는 이러한 파일을 페이지 파일이라고 합니다. 각 파일에는 page-size-bytes 특성으로 설정된 최대 구성된 메시지 크기까지 메시지가 포함되어 있습니다.

시스템은 필요에 따라 페이지 파일을 탐색하고 페이지에 있는 모든 메시지를 클라이언트에서 수신한 즉시 페이지 파일을 제거합니다.

주의

성능상의 이유로 JBoss EAP 메시징은 페이지된 메시지를 스캔하지 않습니다. 따라서 메시지를 그룹화하거나 마지막 값을 제공하기 위해 구성된 큐에서 페이징을 비활성화해야 합니다. 또한 페이징이 활성화된 큐에는 메시지 우선 순위 지정 및 메시지 선택기가 예상대로 작동하지 않습니다. 이러한 기능이 예상대로 작동하려면 페이징을 비활성화해야 합니다

예를 들어 소비자에게 대기열의 메시지를 읽는 메시지 선택기가 있는 경우 선택기와 일치하는 메모리의 메시지만 소비자에게 전달됩니다. 소비자가 이러한 메시지 전달을 승인하면 새 메시지가 페이지 취소되고 메모리에 로드됩니다. 페이지 파일의 디스크에 소비자의 선택기와 일치하는 메시지가 있을 수 있지만, JBoss EAP 메시징은 다른 소비자가 메모리의 메시지를 읽고 사용 가능한 공간을 제공할 때까지 메모리에 로드하지 않습니다. 사용 가능한 공간을 사용할 수 없는 경우 선택기를 사용하는 소비자가 새 메시지를 수신하지 못할 수 있습니다.

11.3. Paging 디렉토리 구성
링크 복사

아래 관리 CLI 명령을 사용하여 페이징 디렉터리의 구성을 읽을 수 있습니다. 이 예제에서 출력에 기본 구성이 표시됩니다. 

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

paging-directory 구성 요소는 페이지 파일을 저장할 파일 시스템의 위치를 지정합니다. JBoss EAP는 이 페이징 디렉터리에서 각 페이징 주소에 대해 하나의 폴더를 만들고 페이지 파일은 이러한 폴더 내에 저장됩니다. 기본적으로 이 경로는 is activemq/paging/ 입니다. 다음 관리 CLI 명령을 사용하여 경로 위치를 변경할 수 있습니다. 

/subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=path,value=PATH_LOCATION)
Copy to Clipboard Toggle word wrap

또한 위의 예제 출력에서 relative-to 특성을 확인합니다. relative-to 가 지정되면 경로 속성의 값은 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)
Copy to Clipboard Toggle word wrap

11.4. 페이징 모드 구성
링크 복사

주소에 전달된 메시지가 구성된 크기를 초과하면 해당 주소는 페이징 모드로 전환됩니다.

참고

페이징은 주소별로 개별적으로 수행됩니다. 주소에 대해 max-size-bytes 를 구성하면 일치하는 각 주소에 지정된 최대 크기가 있습니다. 그러나 일치하는 모든 주소의 전체 크기가 max-size-bytes 로 제한된다는 것은 아닙니다.

페이지 모드에서도 메모리 부족 오류로 인해 서버가 충돌할 수 있습니다. 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)
Copy to Clipboard Toggle word wrap

다음 관리 CLI 명령을 사용하여 주소의최대 크기(max-size-bytes)를 구성할 수 있습니다. 

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:write-attribute(name=max-size-bytes,value=MAX_SIZE)
Copy to Clipboard Toggle word wrap

address 설정의 다른 페이징 관련 속성에 대한 값을 읽거나 쓸 때 유사한 구문을 사용합니다. 아래 테이블에는 설명 및 기본값과 함께 각 속성이 나열되어 있습니다.

다음 표에서는 주소 설정에 대한 매개변수를 설명합니다.

Expand
표 11.1. 주소 설정에 대한 페이징 구성
요소설명

address-full-policy

이 속성의 값은 페이징 결정에 사용됩니다. 유효한 값은 아래에 나열되어 있습니다.

PAGE
설정된 제한을 disk로 설정하지 않고 페이징 및 페이지 메시지를 활성화합니다.
DROP
설정된 제한을 초과하는 메시지를 자동으로 삭제합니다.
FAIL
메시지를 삭제하고 클라이언트 메시지 생산자에게 예외를 보냅니다.
블록
설정된 제한을 넘어 메시지를 전송할 때 클라이언트 메시지 생산자를 차단합니다.

기본값은 PAGE 입니다.

max-size-bytes

이는 페이징 모드로 들어가기 전에 주소가 가질 수 있는 최대 메모리 크기를 지정하는 데 사용됩니다. 기본값은 10485760 입니다.

page-max-cache-size

시스템은 페이지 파일을 메모리의 page-max-cache-size 로 유지하여 페이징 탐색 중에 Input/Output을 최적화합니다. 기본값은 5 입니다.

page-size-bytes

이는 페이징 시스템에서 사용되는 각 페이지 파일의 크기를 지정하는 데 사용됩니다. 기본값은 2097152 입니다.

중요

기본적으로 모든 주소는 주소가 max-size-bytes 에 도달한 후 메시지를 페이지하도록 구성됩니다. 최대 크기에 도달했을 때 메시지를 페이징하지 않으려면 메시지를 삭제하거나 클라이언트 측에 예외가 있는 메시지를 삭제하거나 address -full-policy를 DROP,FAIL, BLOCK 각각으로 설정하여 추가 메시지를 전송하지 못하도록 주소를 구성할 수 있습니다.

대상이 메시지를 페이지하기 시작한 후 address-full-policy 를 PAGE 에서 BLOCK 으로 변경하면 소비자가 더 이상 페이지화된 메시지를 사용할 수 없습니다.

여러 대기열이 있는 주소

메시지가 여러 대기열이 바인딩된 주소로 라우팅되면 메모리에 있는 단일 메시지 사본만 있습니다. 각 큐는 이 원래 메시지 복사본에 대한 참조만 처리하므로 원래 메시지를 참조하는 모든 큐가 메시지를 전달한 경우에만 메모리가 확보됩니다.

참고

단일 지연 큐/서브스크립션을 사용하면 모든 큐에 페이징 시스템의 추가 스토리지를 통해 메시지가 전송되므로 전체 주소의 입력/출력 성능이 저하될 수 있습니다.

12장. 대용량 메시지 작업
링크 복사

클라이언트 또는 서버에 메모리 양이 제한된 경우에도 JBoss EAP 메시징은 대용량 메시지를 지원합니다. 대용량 메시지는 그대로 스트리밍하거나 더 효율적으로 전송하도록 압축할 수 있습니다. 사용자는 메시지 본문에 InputStream 을 설정하여 큰 메시지를 보낼 수 있습니다. 메시지가 전송되면 JBoss EAP 메시징에서 이 InputStream 을 읽고 서버 내용으로 데이터를 전송합니다.

클라이언트와 서버는 메모리에 큰 메시지의 전체 본문을 저장하지 않습니다. 소비자는 처음에 빈 본문이 있는 큰 메시지를 수신하고 메시지에 OutputStream 을 설정하여 내용을 디스크 파일로 스트리밍합니다.

주의

큰 메시지를 처리할 때 서버는 메시지 본문과 동일한 방식으로 메시지 속성을 처리하지 않습니다. 예를 들어, 속성이 journal-buffer-size 보다 큰 문자열로 설정된 메시지는 저널 버퍼를 덮어 쓰기 때문에 서버에서 처리할 수 없습니다.

12.1. 큰 메시지 스트리밍
링크 복사

표준 방식으로 대용량 메시지를 보내는 경우 메시지 크기를 4배 이상 보낼 수 있습니다. 즉, 1GB 메시지에 힙 메모리에 4GB가 필요할 수 있습니다. 이러한 이유로 JBoss EAP 메시징은 메모리가 훨씬 적은 java.io. InputStream 및 java.io.OutputStream 클래스를 사용하여 메시지 본문을 설정할 수 있도록 지원합니다. 입력 스트림은 메시지를 전송하는 데 직접 사용되며 출력 스트림은 메시지를 수신하는 데 사용됩니다.

메시지를 수신할 때 출력 스트림을 처리하는 두 가지 방법이 있습니다.

  • 출력 스트림은 ClientMessage.saveToOutputStream(OutputStream out) 메서드를 사용하여 복구하는 동안 차단할 수 있습니다.
  • ClientMessage.setOutputstream(OutputStream out) 메서드를 사용하여 메시지를 비동기적으로 스트림에 작성할 수 있습니다. 이 방법을 사용하려면 메시지가 완전히 수신될 때까지 소비자가 활성 상태로 유지해야 합니다.

java.io.InputStream을 구현하여 메시지를 전송하는 데 java.io.InputStream 및 메시지를 수신하기 위해 java.io. OutputStream과 같이 파일, JDBC Blobs 또는 SocketInputStream 과 같은 종류의 스트림을 사용할 수 있습니다.

코어 API를 사용하여 큰 메시지 스트리밍

다음 표는 개체 속성을 사용하여 Jakarta Messaging을 통해 사용할 수 있는 ClientMessage 클래스에서 사용할 수 있는 메서드를 보여줍니다.

Expand
ClientMessage 방법설명자카르타 메시징 동등 속성

setBodyInputStream(InputStream)

전송 시 메시지 본문을 읽는 데 사용된 InputStream 을 설정합니다.

JMS_AMQ_InputStream

setOutputStream(OutputStream)

메시지 본문을 수신할 OutputStream 을 설정합니다. 이 방법은 차단하지 않습니다.

JMS_AMQ_OutputStream

saveOutputStream(OutputStream)

메시지 본문을 OutputStream 에 저장합니다. 전체 콘텐츠가 OutputStream 으로 전송될 때까지 차단됩니다.

JMS_AMQ_SaveStream

다음 코드 예제에서는 핵심 메시지를 수신할 때 출력 스트림을 설정합니다. 

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);
Copy to Clipboard Toggle word wrap

다음 코드 예제에서는 핵심 메시지를 보낼 때 입력 스트림을 설정합니다. 

ClientMessage clientMessage = session.createMessage();
clientMessage.setInputStream(dataInputStream);
Copy to Clipboard Toggle word wrap
참고

2GiB보다 큰 메시지의 경우 _AMQ_LARGE_SIZE 메시지 속성을 사용해야 합니다. 이는 getBodySize() 메서드가 최대 정수 값으로 제한되기 때문에 잘못된 값을 반환하기 때문입니다.

자카르타 메시징을 통해 큰 메시지 스트리밍

Jakarta Messaging을 사용하는 경우 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);
Copy to Clipboard Toggle word wrap

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);
Copy to Clipboard Toggle word wrap

또한 OutputStream 은 JMS_AMQ_OutputStream 속성을 사용하여 차단되지 않은 방식으로 설정할 수도 있습니다. 

// This does not wait for the stream to finish. You must keep the consumer active.
messageReceived.setObjectProperty("JMS_AMQ_OutputStream", bufferedOutput);
Copy to Clipboard Toggle word wrap
참고

Jakarta Messaging을 사용하여 대규모 메시지를 스트리밍할 때 StreamMessage 및 BytesMessage 오브젝트만 지원됩니다.

12.2. 큰 메시지 구성
링크 복사

12.2.1. 큰 메시지 위치 설정
링크 복사

아래 관리 CLI 명령을 사용하여 대용량 메시지 디렉터리의 구성을 읽을 수 있습니다. 기본 구성을 강조 표시하기 위해 출력도 포함되어 있습니다. 

/subsystem=messaging-activemq/server=default/path=large-messages-directory:read-resource
{
    "outcome" => "success",
    "result" => {
        "path" => "activemq/largemessages",
        "relative-to" => "jboss.server.data.dir"
    }
}
Copy to Clipboard Toggle word wrap
중요

최상의 성능을 얻으려면 메시지 저널 또는 페이징 디렉터리와 다른 물리 볼륨에 대용량 메시지 디렉터리를 저장하는 것이 좋습니다.

large-messages-directory 구성 요소는 큰 메시지를 저장할 파일 시스템의 위치를 지정하는 데 사용됩니다. 기본적으로 경로 is activemq/largemessages. 다음 관리 CLI 명령을 사용하여 경로의 위치를 변경할 수 있습니다. 

/subsystem=messaging-activemq/server=default/path=large-messages-directory:write-attribute(name=path,value=PATH_LOCATION)
Copy to Clipboard Toggle word wrap

또한 위의 출력에서 relative-to 특성을 확인합니다. relative-to 를 사용하는 경우 경로 속성의 값은 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=large-messages-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)
Copy to Clipboard Toggle word wrap
큰 메시지 크기 구성

관리 CLI를 사용하여 대규모 메시지의 현재 구성을 봅니다. 이 구성은 connection-factory 요소의 일부입니다. 예를 들어 포함된 기본 RemoteConnectionFactory 의 현재 구성을 읽으려면 다음 명령을 사용합니다. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-attribute(name=min-large-message-size)
Copy to Clipboard Toggle word wrap

유사한 구문을 사용하여 속성을 설정합니다. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=min-large-message-size,value=NEW_MIN_SIZE)
Copy to Clipboard Toggle word wrap
참고

min-large-message-size 특성 값은 바이트로 설정해야 합니다.

큰 메시지 압축 구성

빠르고 효율적인 전송을 위해 대용량 메시지를 압축하도록 선택할 수 있습니다. 모든 압축/압축 해제 작업은 클라이언트 측에서 처리됩니다. 압축 메시지가 min-large-message 크기 보다 작으면 일반 메시지로 서버로 전송됩니다. 관리 CLI를 사용하여 부울 속성 compress-large-messages 를 true 로 설정하여 대용량 메시지를 압축합니다. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=compress-large-messages,value=true)
Copy to Clipboard Toggle word wrap

12.2.2. 코어 API를 사용하여 대용량 메시지 크기 구성
링크 복사

클라이언트 측의 코어 API를 사용하는 경우 setMinLargeMessageSize 메서드를 사용하여 대규모 메시지의 최소 크기를 지정해야 합니다. 대용량 메시지의 최소 크기(min-large-message-size)는 기본적으로 100KB로 설정됩니다. 

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

locator.setMinLargeMessageSize(25 * 1024);

ClientSessionFactory factory = ActiveMQClient.createClientSessionFactory();
Copy to Clipboard Toggle word wrap

13장. 메시지 예약
링크 복사

메시지 배달을 위해 앞으로 가장 빠른 시간에 시간을 지정할 수 있습니다. 이 작업은 메시지가 전송되기 전에 _AMQ_SCHED_DELIVERY 예약된 배달 속성을 설정하여 수행할 수 있습니다.

지정된 값은 메시지를 전달할 시간(밀리초)에 해당하는 양의 길이 여야 합니다. 다음은 Jakarta Messaging API를 사용하여 예약된 메시지를 보내는 예입니다. 

// Create a message to be delivered in 5 seconds
TextMessage message = session.createTextMessage("This is a scheduled message message that will be delivered in 5 sec.");
message.setLongProperty("_AMQ_SCHED_DELIVERY", System.currentTimeMillis() + 5000);
producer.send(message);

...

// The message will not be received immediately, but 5 seconds later
TextMessage messageReceived = (TextMessage) consumer.receive();
Copy to Clipboard Toggle word wrap

또한 메시지 보내기 전에 _AMQ_SCHED_DELIVERY 속성을 설정하여 코어 API를 사용하여 예약된 메시지를 보낼 수도 있습니다.

14장. 임시 대기열 및 런타임 대기열
링크 복사

클라이언트에서 요청을 보내고 응답을 대기하는 요청-응답 패턴을 설계할 때 클라이언트의 런타임 인스턴스에 응답 전용 큐가 필요한지 또는 런타임 인스턴스가 공유 큐에 액세스할 수 있는지 여부와 적절한 특성을 기반으로 특정 응답 메시지를 선택해야 합니다.

여러 큐가 필요한 경우 클라이언트는 대기열을 동적으로 만드는 기능이 필요합니다. Jakarta Messaging은 임시 대기열의 개념을 사용하여 이 기능을 제공합니다. TemporaryQueue 는 세션에서 요청 시 생성됩니다. 연결 수명 동안 존재합니다(예: 연결이 닫힐 때까지 또는 임시 큐가 삭제될 때까지). 즉, 특정 세션에서 임시 대기열을 생성하지만 동일한 연결에서 생성된 다른 세션에서 재사용할 수 있습니다.

공유 큐와 응답에 대한 개별 임시 대기열을 사용하는 장단점은 잠재적인 활성 클라이언트 인스턴스 수에 영향을 받습니다. 공유 대기열 접근법에서는 일부 공급자별 임계값에서 큐 액세스에 대한 경합이 문제가 될 수 있습니다. 이는 런타임에 큐 스토리지를 생성하는 공급자와 관련된 추가 오버헤드 및 잠재적으로 많은 임시 대기열을 호스팅하는 시스템 메모리에 미치는 영향과 대조되어야 합니다.

다음 예제에서는 시작 시 각 클라이언트에 대해 임시 대기열 및 소비자를 생성합니다. 각 메시지의 JMSReplyTo 속성을 임시 대기열로 설정한 다음 각 메시지에 상관 관계 ID를 설정하여 요청 메시지를 응답 메시지와 상호 연결합니다. 이렇게 하면 비용이 많이 드는 각 요청의 소비자를 생성 및 종료하는 오버헤드가 방지됩니다. 동일한 생산자 및 소비자는 여러 스레드에서 공유하거나 풀링할 수 있습니다. 세션이 종료될 때 아직 승인되지 않은 메시지가 수신되었지만 아직 승인되지 않은 메시지는 소비자가 다음에 큐에 액세스할 때 유지되고 재배포됩니다.

예제: 임시 대기열 코드

...
// Create a temporary queue, one per client
Destination temporaryQueue = session.createTemporaryQueue();
MessageConsumer responseConsumer = session.createConsumer(temporaryQueue);

// This class handles messages to the temporary queue
responseConsumer.setMessageListener(this);

// Create the message to send
TextMessage textMessage = session.createTextMessage();
textMessage.setText("My new message!");

// Set the reply to field and correlation ID
textMessage.setJMSReplyTo(temporaryQueue);
textMessage.setJMSCorrelationID(myCorrelationID);

producer.send(textMessage);
...
Copy to Clipboard Toggle word wrap

유사한 방식으로 Session.createTemporaryTopic() 메서드를 사용하여 임시 항목을 생성합니다.

15장. 표현식 및 메시지 선택기 필터링
링크 복사

JBoss EAP의 messaging-activemq 하위 시스템은 SQL 92 식 구문의 하위 집합을 기반으로 강력한 필터 언어를 제공합니다.

자카르타 메시징 선택기에 사용되는 구문과 동일하지만 미리 정의된 식별자는 다릅니다. Jakarta Messaging selector 구문에 대한 설명서는 javax.jms.Message 인터페이스 Javadoc를 참조하십시오.

filter 특성은 구성 내의 여러 위치에서 찾을 수 있습니다.

  • 사전 정의된 대기열. 큐를 사전 정의할 때 필터 표현식을 정의할 수 있습니다. 필터 표현식과 일치하는 메시지만 큐에 들어갑니다. 아래 구성 스니펫은 필터를 포함하는 큐 정의를 보여줍니다. 

    <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  ...
  <queue
    name="myQueue"
    filter="FILTER_EXPRESSION"
    ...
  />
  ...
</subsystem>
    Copy to Clipboard Toggle word wrap

    관리 CLI에서 선택기를 사용하여 큐를 생성하려면 다음과 같은 명령을 사용합니다. 

    jms-queue add --queue-address=QUEUE_ADDRESS --selector=FILTER_EXPRESSION
    Copy to Clipboard Toggle word wrap

  • 코어 브리지는 선택적 필터 표현식을 사용하여 정의할 수 있으며 일치하는 메시지만 브리지됩니다. 다음은 messaging-activemq 하위 시스템에 필터가 있는 브리지가 포함된 샘플 구성 파일의 코드 조각입니다. 

    <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  ...
  <bridge
    name="myBridge"
    filter="FILTER_EXPRESSION"
    ...
  />
  ...
</subsystem>
    Copy to Clipboard Toggle word wrap

  • 다중 항목은 선택 사항인 필터 표현식을 사용하여 정의할 수 있으며 일치하는 메시지만 변경됩니다. 자세한 내용은 다음을 참조하십시오. 아래 코드 조각 예제는 필터를 사용하여 한 개씩 보여 줍니다. 

    <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  ...
  <divert
    name="myDivert"
    filter="FILTER_EXPRESSION"
    ...
  />
  ...
</subsystem>
    Copy to Clipboard Toggle word wrap

자카르타 메시징 선택기 식과 JBoss EAP 메시징 핵심 필터 식 사이에는 몇 가지 차이점이 있습니다. Jakarta Messaging 선택기 표현식은 자카르타 메시징 메시지에서 작동하는 반면 JBoss EAP 메시징 코어 필터 표현식은 핵심 메시지에서 작동합니다.

핵심 메시지의 특성을 참조하기 위해 핵심 필터 표현식에서 다음 식별자를 사용할 수 있습니다.

  • AMQP 우선 순위. 메시지의 우선 순위를 참조하려면 다음을 수행합니다. 메시지 우선순위는 0 - 9 의 유효한 값이 있는 정수입니다. 0 은 가장 낮은 우선 순위이고 9 는 가장 높은 우선 순위입니다. 예를 들어 AMQPriority = 3 AND animal = 'aardvark'입니다.
  • AMQExpiration. 메시지의 만료 시간을 참조하려면 다음을 수행합니다. 값은 긴 정수입니다.
  • AMQDurable. 메시지가 지속적인지 여부를 참조하려면 다음을 수행합니다. 값은 유효한 값이 있는 문자열입니다. DURABLE 또는 NON_DURABLE.
  • AMQTimestamp. 메시지가 생성된 시기의 타임 스탬프입니다. 값은 긴 정수입니다.
  • AMQSize. 메시지 크기(바이트)입니다. 값은 정수입니다.

핵심 필터 표현식에 사용되는 기타 식별자는 메시지의 속성으로 간주됩니다.

16장. 메시지 만료 설정
링크 복사

전송된 메시지는 지정된 시간 후에 소비자에게 전달되지 않는 경우 서버에 만료되도록 설정할 수 있습니다. 나중에 만료된 메시지를 사용하여 추가 검사를 수행할 수 있습니다.

코어 API를 사용하여 메시지 만료 설정

핵심 API를 사용하여 setExpiration 방법을 사용하여 메시지에 만료 시간을 설정할 수 있습니다. 

// The message will expire 5 seconds from now
message.setExpiration(System.currentTimeMillis() + 5000);
Copy to Clipboard Toggle word wrap

자카르타 메시징을 사용하여 메시지 만료 설정

자카르타 Messaging MessageProducer 가 메시지를 전송할 때 사용할 수 있는 시간을 설정할 수 있습니다. setTimeToLive 메서드를 사용하여 이 값을 밀리초 단위로 지정합니다. 

// Messages sent by this producer will be retained for 5 seconds before expiring
producer.setTimeToLive(5000);
Copy to Clipboard Toggle word wrap

또한 생산자의 send 메서드에 시간을 유지하도록 설정하여 메시지 만료를 메시지별로 지정할 수도 있습니다. 

// The last parameter of the send method is the time to live, in milliseconds
producer.send(message, DeliveryMode.PERSISTENT, 0, 5000)
Copy to Clipboard Toggle word wrap

만료 주소에서 사용하는 만료된 메시지에는 다음과 같은 속성이 있습니다.

  • _AMQ_ORIG_ADDRESS

    만료된 메시지의 원래 주소를 포함하는 String 속성입니다.

  • _AMQ_ACTUAL_EXPIRY

    만료된 메시지의 실제 만료 시간을 포함하는 Long 속성입니다.

16.1. 만료 주소
링크 복사

만료 주소를 설정하여 만료된 메시지를 보낼 위치를 지정할 수 있습니다. 메시지가 만료되고 만료 주소가 지정되지 않은 경우 메시지가 큐에서 제거되고 삭제됩니다.

관리 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)
Copy to Clipboard Toggle word wrap

16.2. 만료 리퍼 스레드
링크 복사

리퍼 스레드는 대기열을 정기적으로 검사하여 메시지가 만료되었는지 확인합니다. 관리 CLI를 사용하여 리퍼 스레드에 대한 검사 기간 및 스레드 우선 순위를 설정할 수 있습니다.

만료 리퍼 스레드의 검사 기간을 설정합니다. 이 기간은 밀리초 단위로 대기열을 스캔하여 만료된 메시지를 탐지합니다. 기본값은 30000 입니다. 리퍼 스레드를 비활성화하려면 이 값을 -1 로 설정할 수 있습니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-scan-period,value=30000)
Copy to Clipboard Toggle word wrap

만료 리퍼 스레드에 대한 스레드 우선 순위를 설정합니다. 가능한 값은 0 에서 9 사이이며 9 는 가장 높은 우선 순위입니다. 기본값은 3 입니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-thread-priority,value=3)
Copy to Clipboard Toggle word wrap

17장. 지연된 재배달 구성
링크 복사

주소에 대한 지연 재배달은 address-setting 구성 요소의 redelivery- delay 특성에 의해 정의됩니다. 재배달 지연이 지정되면 JBoss EAP는 메시지를 다시 보내기 전에 이 지연 기간을 기다립니다. redelivery-delay 를 0 으로 설정하면 재배달 지연이 없습니다. 지정된 address-setting 에 대한 redelivery-delay 의 현재 값을 가져오려면 다음 관리 CLI 명령을 예제로 사용합니다. 

/subsystem=messaging-activemq/server=default/address-setting=YOUR_ADDRESS_SETTING:read-attribute(name=redelivery-delay)
Copy to Clipboard Toggle word wrap

아래 표에는 메시지 재배달을 구성하는 데 사용할 수 있는 address-setting 의 구성 속성이 나열되어 있습니다. 다음 관리 CLI 명령을 예제로 사용하여 제공된 특성의 값을 설정합니다. 

/subsystem=messaging-activemq/server=default/address-setting=YOUR_ADDRESS_SETTING:write-attribute(name=ATTRIBUTE,value=NEW_VALUE)
Copy to Clipboard Toggle word wrap
Expand
표 17.1. 주소 설정의 배달 관련 속성
속성설명

max-delivery-attempts

취소된 메시지를 dead-letter-address 로 보내기 전에 재전송할 수 있는 시간을 정의합니다. 기본값은 10입니다.

max-redelivery-delay

밀리초 단위의 redelivery-delay 의 최대값입니다. 지연이 너무 커지지 않도록 max-redelivery-delay 매개변수를 설정할 수 있습니다. 기본값은 redelivery-delay * 10 입니다.

redelivery-delay

취소된 메시지를 재배달하기 전에 밀리초 단위로 대기하는 시간을 정의합니다. 기본값은 0입니다.

redelivery-multiplier

redelivery-delay 매개변수에 적용되는 승수입니다. 메시지가 다시 전송될 때마다 지연 기간은 이전 re delivery-delay * redelivery- multiplier 와 동일합니다. 기본값은 1.0 입니다.

address-setting 구성에 대한 자세한 내용은 주소 설정을 참조하십시오.

18장. 데드 문자 주소 구성
링크 복사

배달 못 한 주소는 messaging -activemq 하위 시스템 구성의 address- setting 요소에 정의됩니다. 지정된 address-setting 에 대한 현재 구성을 읽으려면 다음 관리 CLI 명령을 예제로 사용합니다. 

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:read-attribute(name=dead-letter-address)
Copy to Clipboard Toggle word wrap

dead-letter-address 를 지정하지 않으면 max-delivery-attempts 시간을 전달한 후 메시지가 제거됩니다. 기본적으로 메시지 배달은 10번 시도됩니다. max-delivery-attempts 를 -1 로 설정하면 무한의 재배달 시도가 가능합니다. 아래 관리 CLI 명령 예제는 지정된 address-setting 에 대해 dead-letter-address 및 max-delivery-attempts 속성을 설정하는 방법을 보여줍니다. 

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:write-attribute(name=dead-letter-address,value=NEW_VALUE)

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:write-attribute(name=max-delivery-attempts,value=NEW_VALUE)
Copy to Clipboard Toggle word wrap

예를 들어 일치하는 주소 집합에 대해 배달 못 한 문자를 전역적으로 설정할 수 있으며 이 주소에만 무한 재배달 시도를 허용하도록 특정 주소 설정에 대해 max-delivery-attempts 를 -1 로 설정할 수 있습니다. 주소 와일드카드를 사용하여 주소 집합의 배달 못 한 설정을 구성할 수도 있습니다.

address-setting 생성 및 구성에 대한 자세한 내용은 주소 설정을 참조하십시오.

19장. 흐름 제어
링크 복사

흐름 제어를 사용하면 메시징 참여자가 부담을 주지 않도록 클라이언트와 서버 간의 메시징 데이터 흐름을 제한할 수 있습니다. 소비자 측과 생산자 측 모두에서 데이터 흐름을 관리할 수 있습니다.

19.1. 소비자 흐름 제어
링크 복사

JBoss EAP 메시징에는 소비자 대신 사전 가져오기할 데이터 양을 정의하고 소비자가 메시지를 사용할 수 있는 속도를 제어하는 구성이 포함되어 있습니다.

창 기반 흐름 제어

JBoss EAP 메시징은 각 소비자의 버퍼에 메시지를 사전 가져오기합니다. 버퍼 크기는 connection- factory 의 consumer-window-size 특성에 따라 결정됩니다. 아래 구성 예에서는 consumer- window -size 특성이 명시적으로 설정된 connection- factory 를 보여줍니다. 

<connection-factory name="MyConnFactory" ... consumer-window-size="1048576" />
Copy to Clipboard Toggle word wrap

관리 CLI를 사용하여 지정된 connection-factory 에 대한 consumer-window-size 특성 값을 읽고 씁니다. 아래 예에서는 InVmConnectionFactory 연결 팩토리를 사용하여 수행한 방법을 보여줍니다. 이 팩토리는 서버와 동일한 가상 시스템에 상주하는 소비자의 기본값입니다(예: 로컬 MessageDrivenBean ).

  • 관리 CLI에서 InVmConnectionFactory의 consumer -window-size 특성을 읽습니다. 
/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:read-attribute(name=consumer-window-size)
{
    "outcome" => "success",
    "result" => 1048576
}
Copy to Clipboard Toggle word wrap
  • 관리 CLI에서 consumer-window-size 속성을 작성합니다. 
/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:write-attribute(name=consumer-window-size,value=1048576)
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

consumer-window-size 의 값은 정수여야 합니다. 아래 표에 명시된 대로 일부 값은 특별한 의미를 갖습니다.

Expand
표 19.1. consumer-window-size 값
현재의설명

n

버퍼 크기를 n 바이트로 설정하는 데 사용되는 정수 값입니다. 기본값은 1048576 이며, 대부분의 경우 문제가 되지 않습니다. 벤치마킹은 기본값이 충분하지 않은 경우 창 크기에 대한 최적의 값을 찾는 데 도움이 됩니다.

0

버퍼링을 끕니다. 이는 느린 소비자에게 도움이 될 수 있으며 여러 소비자에 걸쳐 결정적인 배포를 제공할 수 있습니다.

-1

바인딩되지 않은 버퍼를 생성합니다. 이를 통해 신속하게 메시지를 수신하는 대로 신속하게 메시지를 가져오고 처리할 수 있는 매우 빠른 소비자가 도움이 될 수 있습니다.

주의

consumer-window-size 를 -1 로 설정하면 소비자가 메시지를 받는 것처럼 빠르게 메시지를 처리할 수 없는 경우 클라이언트 메모리가 오버플로될 수 있습니다.

코어 API를 사용하는 경우 set ConsumerWindowSize() 메서드를 사용하여 ServerLocator 에서 소비자 창 크기를 설정 할 수 있습니다.

Jakarta Messaging을 사용하는 경우 클라이언트는 인스턴스화 ConnectionFactory 의 setConsumerWindowSize() 메서드를 사용하여 소비자 창 크기를 지정할 수 있습니다.

속도 제한 흐름 제어

JBoss EAP 메시징은 제한이라고 하는 흐름 제어 방법인 초당 사용하는 메시지의 속도를 조정할 수 있습니다. 적절한 connection-factory의 consumer-max- rate 특성을 사용하여 소비자가 지정된 속도보다 빠른 속도로 메시지를 사용하지 않도록 합니다. 

<connection-factory name="MyConnFactory" ... consumer-max-rate="10" />
Copy to Clipboard Toggle word wrap

기본값은 -1 로, 속도 제한 흐름 제어를 비활성화합니다.

관리 CLI는 consumer-max-rate 특성을 읽고 쓰는 데 권장되는 방법입니다. 아래 예에서는 InVmConnectionFactory 연결 팩토리(예: 로컬 MessageDrivenBean )와 동일한 가상 시스템에 상주하는 소비자의 기본값인 InVmConnectionFactory 연결 팩토리를 사용하여 수행한 방법을 보여줍니다.

  • 관리 CLI를 사용하여 consumer-max-rate 속성 읽기 
/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:read-attribute(name=consumer-max-rate)
{
    "outcome" => "success",
    "result" => -1
}
Copy to Clipboard Toggle word wrap
  • 관리 CLI를 사용하여 consumer-max-rate 속성을 작성합니다. 
/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:write-attribute(name=consumer-max-rate,value=100)
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

Jakarta Messaging을 사용하는 경우 인스턴스화된 ConnectionFactory 의 setConsumerMaxRate(int consumerMaxRate) 방법을 사용하여 최대 속도 크기를 설정할 수 있습니다.

Core API를 사용하는 경우 속도는 ServerLocator.setConsumerMaxRate(int consumerMaxRate) 메서드로 설정할 수 있습니다.

19.2. 생산자 흐름 제어
링크 복사

또한 JBoss EAP 메시징은 서버가 너무 많은 메시지를 받지 못하도록 클라이언트에서 전송되는 데이터 양을 제한할 수도 있습니다.

창 기반 흐름 제어

JBoss EAP 메시징은 메시지 생산자를 크레딧 교환을 사용하여 조정합니다. 생성자는 충분한 크레딧을 보유하는 한 주소로 메시지를 전송할 수 있습니다. 메시지를 전송하는 데 필요한 크레딧 양은 크기에 따라 결정됩니다. 생산자가 크레딧 상태가 낮을 때 서버에서 더 많은 것을 요청해야 합니다. 서버 구성 내에서 생산자가 한 번에 요청할 수 있는 크레딧 양을 connection -factory 요소의 특성인 producer-window- size 라고 합니다. 

<connection-factory name="MyConnFactory" ... producer-window-size="1048576" />
Copy to Clipboard Toggle word wrap

창 크기는 한 번에 진행 중일 수 있는 바이트의 양을 결정하여 원격 연결이 서버에 과부하되지 않도록 합니다.

관리 CLI를 사용하여 지정된 연결 팩토리의 producer-window-size 특성을 읽고 씁니다. 아래 예제에서는 원격 클라이언트에서 사용할 기본 구성 및 용도인 RemoteConnectionFactory 를 사용합니다.

  • 관리 CLI를 사용하여 producer-window-size 특성을 읽습니다. 
subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-attribute(name=producer-window-size)
{
    "outcome" => "success",
    "result" => 65536
}
Copy to Clipboard Toggle word wrap
  • 관리 CLI를 사용하여 producer-window-size 특성을 작성합니다. 
/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=producer-window-size,value=65536)
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

Jakarta Messaging을 사용하는 경우 클라이언트는 ConnectionFactory 의 setProducerWindowSize(int producerWindowSize) 메서드를 호출하여 창 크기를 직접 설정할 수 있습니다.

코어 API를 사용하는 경우 ServerLocator 의 setProducerWindowSize(int producerWindowSize) 메서드를 사용하여 창 크기를 설정할 수 있습니다.

생산자 창 기반 흐름 제어 차단

일반적으로 메시징 서버는 항상 요청한 크레딧 수와 동일한 수를 제공합니다. 그러나 서버에서 전송한 크레딧 수를 제한할 수 있으므로 한 번에 처리할 수 있는 것보다 더 많은 메시지를 전송하는 생산자가 메모리 부족을 방지할 수 있습니다.

예를 들어 myqueue 라는 자카르타 메시징 큐가 있고 최대 메모리 크기를 10MB로 설정하면 서버는 크기가 10MB를 초과하지 않도록 대기열의 메시지 수를 조정합니다. 주소가 가득 차면 생산자가 주소에서 충분한 공간을 확보할 때까지 클라이언트 측에서 차단됩니다.

참고

생산자 흐름 제어 차단은 생산자를 차단하지 않고 스토리지에 대한 메시지를 페이지하는 페이징에 대한 대체 접근법입니다. 자세한 내용은 Paging 정보를 참조하십시오.

address-setting 구성 요소에는 차단 생산자 흐름 제어를 관리하는 구성이 포함되어 있습니다. address-setting 은 해당 주소에 등록된 모든 큐에 구성 세트를 적용하는 데 사용됩니다. 수행 방법에 대한 자세한 내용은 주소 설정 구성을 참조하십시오.

생산자 흐름 제어를 차단해야 하는 각 address-setting 에 대해 max-size-bytes 특성의 값을 포함해야 합니다. 해당 주소에 바인딩된 모든 큐의 총 메모리는 max-size-bytes 를 초과할 수 없습니다. Jakarta Messaging 주제의 경우 주제의 모든 서브스크립션의 총 메모리는 max-size-bytes 를 초과할 수 없습니다.

또한 address-full-policy 특성을 BLOCK (차단)으로 설정해야 하므로 서버에서 max- size-bytes 에 도달하는 경우 생산자가 차단되어야 함을 알 수 있습니다. 다음은 두 특성이 모두 설정된 address-setting 의 예입니다. 

<address-setting ...
      name="myqueue"
      address-full-policy="BLOCK"
      max-size-bytes="100000" />
Copy to Clipboard Toggle word wrap

위의 예제에서는 자카르타 메시징 대기열 "myqueue"의 최대 크기를 100000 바이트로 설정합니다. 생산자는 최대 크기에 도달하면 해당 주소로 전송하지 못하도록 차단됩니다.

다음 예제와 같이 관리 CLI를 사용하여 이러한 속성을 설정합니다.

  • 지정된 address -setting에 대해 max-size- bytes설정 
/subsystem=messaging-activemq/server=default/address-setting=myqueue:write-attribute(name=max-size-bytes,value=100000)
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
  • 지정된 address- setting에 대한 address-full-policy 설정 
/subsystem=messaging-activemq/server=default/address-setting=myqueue:write-attribute(name=address-full-policy,value=BLOCK)
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
속도 제한 흐름 제어

JBoss EAP 메시징은 다음 예와 같이 connection-factory 에 대해 producer-max-rate 를 지정하는 경우 생산자가 초당 보낼 수 있는 메시지 수를 제한합니다. 

<connection-factory name="MyConnFactory" producer-max-rate="1000" />
Copy to Clipboard Toggle word wrap

기본값은 -1 로, 속도 제한 흐름 제어를 비활성화합니다.

관리 CLI를 사용하여 producer-max-rate 의 값을 읽고 씁니다. 아래 예제에서는 원격 클라이언트에서 사용할 기본 구성 및 용도인 RemoteConnectionFactory 를 사용합니다.

  • producer-max-rate 특성 값을 읽습니다. 
/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-attribute(name=producer-max-rate)
{
    "outcome" => "success",
    "result" => -1
}
Copy to Clipboard Toggle word wrap
  • producer-max-rate 특성 값을 작성합니다. 
/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=producer-max-rate,value=100)
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

코어 API를 사용하는 경우 ServerLocator.setProducerMaxRate(int producerMaxRate) 메서드를 사용하여 속도를 설정합니다.

JNDI를 사용하여 연결 팩토리를 인스턴스화하고 조회하는 경우 인스턴스화 연결 팩토리의 setProducerMaxRate(int producerMaxRate) 메서드를 사용하여 클라이언트에 최대 속도를 설정할 수 있습니다.

20장. 사전 승인 구성
링크 복사

Jakarta Messaging은 세 가지 승인 모드를 지정합니다.

  • AUTO_ACKNOWLEDGE
  • CLIENT_ACKNOWLEDGE
  • DUPS_OK_ACKNOWLEDGE

경우에 따라 오류 발생 시 메시지를 손실할 수 있으므로 클라이언트에 전달하기 전에 서버의 메시지를 확인하는 것이 좋습니다. 이 추가 모드는 JBoss EAP 메시징에서 지원되며 사전 잠금 모드라고 합니다.

전달하기 전에 서버에서 미리 승인하는 단점은 메시지를 승인한 후 서버의 시스템이 충돌하지만 클라이언트에 배달되기 전에 서버의 시스템이 충돌하면 메시지가 손실된다는 것입니다. 이 경우 메시지가 손실되고 시스템이 다시 시작되면 복구되지 않습니다.

메시징 케이스에 따라 사전 알림 모드는 메시지 손실로 인해 추가 네트워크 트래픽 및 CPU 사용량을 방지할 수 있습니다.

사전 통지의 사용 사례는 주가 업데이트 메시지의 예입니다. 이 메시지를 사용하면 다음 가격 업데이트 메시지가 곧 도착하여 이전 가격을 재정의하므로 충돌이 발생할 경우 메시지를 손실하는 것이 타당할 수 있습니다.

참고

사전 잠금 모드를 사용하는 경우 트랜잭션을 커밋할 때가 아니라 서버에서 먼저 승인되는 메시지에 대한 트랜잭션 의미 체계가 손실됩니다.

20.1. 서버 구성
링크 복사

다음과 같이 관리 CLI를 사용하여 pre-acknowledge 특성을 true 로 설정하여 사전acknowledge 모드를 사용하도록 연결 팩토리를 구성할 수 있습니다. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=pre-acknowledge,value=true)
Copy to Clipboard Toggle word wrap

20.2. 클라이언트 구성
링크 복사

Pre-acknowledge 모드는 클라이언트의 JNDI 컨텍스트 환경에서 jndi.properties 파일에서 구성할 수 있습니다. 

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connection.ConnectionFactory=tcp://localhost:8080?preAcknowledge=true
Copy to Clipboard Toggle word wrap

또는 Jakarta Messaging API를 사용하여 사전 잠금 모드를 사용하려면 ActiveMQSession.PRE_ACKNOWLEDGE 상수로 자카르타 메시징 세션을 생성합니다. 

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

21장. 인터셉터
링크 복사

JBoss EAP 메시징은 서버에 들어오고 종료하는 패킷을 가로채는 인터셉터를 지원합니다. 들어오는 인터셉터는 각각 서버를 시작하거나 종료하는 모든 패킷에 대해 호출됩니다. 이렇게 하면 패킷 감사 또는 필터링과 같은 사용자 지정 코드를 실행할 수 있습니다. 인터셉터는 가로채는 패킷을 수정할 수 있습니다. 이로 인해 인터셉터가 강력하지만 잠재적으로 위험할 수 있습니다.

21.1. 인터셉터 구현
링크 복사

인터셉터는 인터셉터 인터페이스를 구현해야 합니다. 

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

public interface Interceptor
{
   boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException;
}
Copy to Clipboard Toggle word wrap

반환된 부울 값은 중요합니다.

  • true가 반환되면 프로세스가 정상적으로 계속됩니다.
  • false가 반환되면 프로세스가 중단되고 다른 인터셉터가 호출되지 않으며 서버에서 패킷이 추가로 처리되지 않습니다.

인터셉터 클래스는 JBoss EAP에 모듈로 추가해야 합니다. 자세한 내용은 JBoss EAP 구성 가이드에서 사용자 지정 모듈 만들기 를 참조하십시오.

21.2. 인터셉터 구성
링크 복사

모듈을 사용자 지정 모듈로 JBoss EAP에 추가한 후 관리 CLI를 사용하여 들어오고 나가는 인터셉터가 메시징 하위 시스템 구성에 추가됩니다.

참고

새 인터셉터 구성이 승인되기 전에 관리자 전용 모드에서 JBoss EAP를 시작해야 합니다. 자세한 내용은 JBoss EAP 구성 가이드에서 관리 전용 모드에서 JBoss EAP 실행을 참조하십시오. 새 구성이 처리되면 서버를 일반 모드로 다시 시작합니다.

각 인터셉터는 아래 예제 관리 CLI 명령에 따라 추가해야 합니다. 이 예제에서는 각 인터셉터가 이미 JBoss EAP에 사용자 지정 모듈로 추가되었다고 가정합니다. 

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

아래 예제와 같이 나가는 인터셉터를 추가하는 방법은 유사한 구문을 따릅니다. 

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

22장. 메시지 그룹화
링크 복사

메시지 그룹은 특정 특성을 공유하는 메시지 그룹입니다.

  • 메시지 그룹의 모든 메시지는 공통 그룹 ID로 그룹화됩니다. 즉, 공통 그룹 속성으로 식별할 수 있습니다.
  • 메시지 그룹의 모든 메시지는 대기열의 고객 수에 관계없이 동일한 소비자가 순차적으로 처리하고 사용합니다. 즉, 고유 그룹 ID가 있는 특정 메시지 그룹은 소비자가 열면 한 소비자가 항상 처리합니다. 소비자가 메시지 그룹을 종료하면 전체 메시지 그룹이 대기열의 다른 소비자로 이동합니다.

메시지 그룹은 그룹 ID와 같은 특정 값의 메시지가 단일 소비자가 직렬로 처리해야 하는 경우 특히 유용합니다.

중요

큐에 페이징이 활성화된 경우 메시지 그룹화가 예상대로 작동하지 않습니다. 메시지 그룹화에 대한 큐를 구성하기 전에 페이징을 비활성화해야 합니다.

메시징 서버 클러스터 내에서 메시지 그룹화를 구성하는 방법에 대한 자세한 내용은 3부에서 Clustered Message Grouping, 여러 메시징 시스템 구성을 참조하십시오.

22.1. 코어 API를 사용하여 메시지 그룹 구성
링크 복사

_AMQ_GROUP_ID 특성은 클라이언트 측의 Core API를 사용하여 메시지 그룹을 식별하는 데 사용됩니다. 임의의 고유한 메시지 그룹 식별자를 선택하려면 SessionFactory 에서 자동 그룹 속성을 true 로 설정할 수도 있습니다.

22.2. 자카르타 메시징을 사용하여 메시지 그룹 구성
링크 복사

JMSXGroupID 속성은 자카르타 메시징 클라이언트의 메시지 그룹을 식별하는 데 사용됩니다. 다른 메시지가 있는 메시지 그룹을 하나의 소비자에게 보내려면 다른 메시지에 대해 동일한 JMSXGroupID 를 설정할 수 있습니다. 

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

message = ...
message.setStringProperty("JMSXGroupID", "Group-0");
producer.send(message);
Copy to Clipboard Toggle word wrap

대체 방법은 클라이언트에서 사용할 connection-factory의 속성인 auto- group 또는 group- id 중 하나를 사용하는 것입니다.

자동 그룹이 true 로 설정되면 connection-factory 는 이를 통해 전송된 모든 메시지에 대해 임의의 고유한 메시지 그룹 식별자를 사용하기 시작합니다. 관리 CLI를 사용하여 자동 그룹 특성을 설정할 수 있습니다. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=auto-group,value=true)
Copy to Clipboard Toggle word wrap

group-id 특성은 연결 팩토리를 통해 전송된 모든 메시지에 대해 지정된 값으로 특성 JMSXGroupID 를 설정합니다. 연결 팩토리에 특정 group-id 를 설정하려면 관리 CLI를 사용합니다. 

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

23장. 다중 경로
링크 복사

diverts는 JBoss EAP 메시징에 구성된 개체로, 한 주소에서 다른 주소로 메시지를 전환하는 데 도움이 됩니다. dists는 다음 유형으로 분류할 수 있습니다.

배타적
메시지는 새 주소로만 전환되며 이전 주소로 전송되지 않습니다.
제외되지 않음
메시지가 이전 주소가 전송되고 복사본도 새 주소로 전송됩니다. 비독점 분산은 메시지 흐름을 분할하는 데 사용할 수 있습니다.

다중 경로는 동일한 서버의 주소로만 메시지를 전환합니다. 다른 서버의 주소로 전환하려는 경우 공통 패턴은 로컬 저장소 및 전달 대기열로 전환한 다음, 해당 대기열에서 사용하는 브리지를 설정하고 다른 서버의 주소로 전달합니다.

따라서 다중 경로는 매우 정교한 개념입니다. 브리지와 결합하면 다중 경로를 사용하여 흥미롭고 복잡한 라우팅을 만들 수 있습니다. 서버의 다중 집합은 메시지의 라우팅 테이블 유형으로 간주할 수 있습니다. 다종과 브리지를 결합하면 여러 지리적으로 분산된 서버 간에 안정적인 라우팅 연결의 분산 네트워크를 생성하여 글로벌 메시징 메시를 만들 수 있습니다. 브리지 사용 방법에 대한 자세한 내용은 코어 브리지 구성을 참조하십시오.

Transformer 및 선택적 메시지 필터를 적용하도록 dists를 구성할 수 있습니다. 선택적 메시지 필터는 지정된 필터와 일치하는 메시지만 전환하는 데 도움이 됩니다. 필터에 대한 자세한 내용은 필터 표현식 및 메시지 선택기를 참조하십시오.

변환기는 메시지를 다른 형식으로 변환하는 데 사용됩니다. 변환기를 지정하면 모든 변조된 메시지가 Transformer 에 의해 변환됩니다. 모든 변환기는 org.apache.activemq.artemis.core.server.cluster.Transformer 인터페이스를 구현해야 합니다. 

package org.apache.activemq.artemis.core.server.cluster;
import org.apache.activemq.artemis.core.server.ServerMessage;

public interface Transformer {
   ServerMessage transform(ServerMessage message);
}
Copy to Clipboard Toggle word wrap

JBoss EAP 메시징을 활성화하여 변환기 구현 인스턴스를 인스턴스화하려면 JBoss EAP 모듈에 해당 모듈을 포함한 다음 해당 모듈을 org.apache.activemq.artemis 모듈에 내보낸 종속성으로 추가해야 합니다. 사용자 지정 모듈을 생성하는 방법에 대한 자세한 내용은 JBoss EAP 구성 가이드에서 사용자 지정 모듈 만들기를 참조하십시오. 종속 항목을 org.apache.activemq.artemis 모듈에 추가하려면 다음 예제와 같이 EAP_HOME/modules/system/layers/base/org/apache/activemq/artemis/main/module.xml 파일을 열고 <module> 을 <dependencies> 목록에 추가합니다. 

<module xmlns="urn:jboss:module:1.3" name="org.apache.activemq.artemis">
    <resources>
      ...
    </resources>
    <dependencies>
      ...
      <module name="YOUR_MODULE_NAME" export="true"/>
    </dependencies>
</module>
Copy to Clipboard Toggle word wrap

23.1. 배타적 다트
링크 복사

다음은 구성에 표시될 수 있는 배타적 변형의 예입니다. 

<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"/>
Copy to Clipboard Toggle word wrap

이 예에서는 price -divert 라는 다양한 구분선이 구성되어 있으며, 이 주소는 jms.topic. PriceUpdates 주소로 전송되는 메시지를 priceUpdates 라고 하는 자카르타 메시징 항목에 매핑하고, 다른 로컬 주소 jms.queue.priceForwarding에 해당하며 priceForwarding 이라는 로컬 자카르타 메시징 큐에 매핑됩니다.

또한 New York 값이 있는 메시지 속성이 있는 메시지 필터 문자열도 지정합니다. 다른 모든 메시지는 계속 일반 주소로 라우팅됩니다. 필터 문자열이 지정되지 않은 경우 모든 메시지가 일치하는 것으로 간주됩니다.

변환기 클래스는 지정됩니다. 이 예제에서 변환기는 변동이 발생한 시간을 기록하는 헤더를 추가합니다.

이 예제는 실제로 메시지를 로컬 저장소로 전환하고 대기열을 전달합니다. 이 대기열은 메시지를 다른 서버의 주소로 전달하는 브리지로 구성됩니다. 자세한 내용은 코어 브리지 구성을 참조하십시오.

23.2. 비독점 변형
링크 복사

아래는 비독점 다중 항목의 예입니다. 비 배타적 다각은 필터 및 변환기 선택 옵션으로 독점적인 다각화와 동일한 방식으로 구성할 수 있습니다. 

<divert
  name="order-divert"
  address="jms.queue.orders"
  forwarding-address="jms.topic.spytopic"
  exclusive="false"/>
Copy to Clipboard Toggle word wrap

위의 dist는 주문 이라는 자카르타 메시징 큐에 매핑되는 jms.queue.orders 주소로 전송된 모든 메시지의 사본을 받아 javaTopic이라는 자카르타 메시징 항목에 해당하는 jms.topic.SpyTopic 라는 로컬 주소로 전송합니다 .

다중 경로 생성

관리 CLI를 사용하여 원하는 dist 유형을 생성합니다. 

/subsystem=messaging-activemq/server=default/divert=my-divert:add(divert-address=news.in,forwarding-address=news.forward)
Copy to Clipboard Toggle word wrap

비독점 변형은 기본적으로 생성됩니다. 배타적 특성을 생성하려면 다음 속성을 사용합니다. 

/subsystem=messaging-activemq/server=default/divert=my-exclusive-divert:add(divert-address=news.in,forwarding-address=news.forward,exclusive=true)
Copy to Clipboard Toggle word wrap

아래 표는 다중 경로의 속성과 해당 설명을 캡처합니다. 다음 명령을 사용하여 관리 CLI에서 이 정보를 표시할 수 있습니다. 

/subsystem=messaging-activemq/server=default/divert=*:read-resource-description()
Copy to Clipboard Toggle word wrap
Expand
속성설명

divert-address

다른 주소. 필수 항목입니다.

배타적

스위트가 배타적인지 여부, 메시지가 새 주소로 전환되고 이전 주소로 이동하지 않음을 의미합니다. 기본값은 false입니다.

filter

선택적 필터 문자열입니다. 지정된 경우 필터 표현식과 일치하는 메시지만 전환합니다.

forwarding-address

대체 대상 주소. 필수 항목입니다.

routing-name

다중 항목의 라우팅 이름입니다.

transformer-class-name

메시지 본문 또는 속성을 전환하기 전에 메시지의 본문 또는 속성을 변환하는 데 사용되는 클래스의 이름입니다.

24장. 스레드 관리
링크 복사

각 JBoss EAP 메시징 서버는 일반 용도로 단일 스레드 풀과 예약된 사용을 위해 예약된 스레드 풀을 유지 관리합니다. Java 예약 스레드 풀은 표준 스레드 풀을 사용하도록 구성할 수 없습니다. 그렇지 않으면 예약된 작업과 예약되지 않은 활동에 단일 스레드 풀을 사용할 수 있습니다.

JBoss EAP는 차단되지 않은 새로운 NIO를 사용합니다. 기본적으로 JBoss EAP 메시징은 들어오는 패킷을 처리하기 위해. getRuntime().availableProcessors() 에서 보고한 대로 코어 수 또는 하이퍼 스레드 수의 세 배에 해당하는 스레드를 사용합니다. 이 값을 재정의하려면 전송 구성에 thenio -remoting-threads 매개변수를 지정하여 스레드 수를 설정합니다. 자세한 내용은 메시징 전송 구성을 참조하십시오.

24.1. 서버 예약 스레드 풀
링크 복사

서버 예약 스레드 풀은 정기적으로 또는 지연을 사용하여 실행해야 하는 서버 측의 대부분의 활동에 사용됩니다. 내부적으로 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)
Copy to Clipboard Toggle word wrap

24.2. 서버 일반 용도 스레드 풀
링크 복사

일반적인 목적 스레드 풀은 서버 측의 대부분의 비동기 작업에 사용됩니다. 내부적으로 java.util.concurrent.ThreadPoolExecutor 인스턴스에 매핑됩니다.

이 풀에서 사용하는 최대 스레드 수는 thread-pool-max-size 특성을 사용하여 구성됩니다.

thread-pool-max-size 가 -1 로 설정된 경우 스레드 풀에는 상한이 없으며 요청을 처리하는 데 사용 가능한 스레드가 충분하지 않은 경우 필요에 따라 새 스레드가 생성됩니다. 나중에 활동이 대체되면 스레드가 시간 초과되고 닫힙니다.

thread-pool-max-size 가 0보다 큰 양의 정수로 설정되면 스레드 풀이 바인딩됩니다. 요청이 들어와 풀에 사용 가능한 스레드가 없으면 스레드를 사용할 수 있을 때까지 요청이 차단됩니다. 상한이 너무 낮은 경우 교착 상태일 수 있으므로 바인딩된 스레드 풀을 주의해서 사용하는 것이 좋습니다.

thread-pool-max-size 의 기본값은 30 입니다. 기본 JBoss EAP 메시징 서버에 새 값을 설정하려면 다음 관리 CLI 명령을 사용합니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=thread-pool-max-size,value=40)
Copy to Clipboard Toggle word wrap

바인딩되지 않은(캐시됨) 및 바인딩된(고정) 스레드 풀에 대한 자세한 내용은 ThreadPoolExecutor Javadoc 를 참조하십시오.

24.3. 서버 스레드 사용률 모니터링
링크 복사

스레드 사용률을 확인하여 스레드 풀의 크기를 적절하게 구성했는지 확인합니다.

스레드 사용률을 확인하려면 다음 CLI 명령을 실행합니다. 

/subsystem=messaging-activemq:read-resource(include-runtime)
Copy to Clipboard Toggle word wrap

시스템에서 다음과 유사한 결과를 반환합니다. 

{
    "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}
    }
}
Copy to Clipboard Toggle word wrap
Expand
표 24.1. 스레드 사용률 데이터
사용률 특성설명

global-client-scheduled-thread-pool-active-count

현재 작업을 실행하는 모든 ActiveMQ 클라이언트에서 사용 중인 예약된 풀 스레드 수입니다.

global-client-scheduled-thread-pool-completed-task-count

서버가 부팅된 이후 모든 ActiveMQ 클라이언트가 실행한 예약된 풀 스레드를 사용하는 작업 수입니다.

global-client-scheduled-thread-pool-current-thread-count

모든 Active MQ 클라이언트에서 사용 중인 예약된 풀의 현재 스레드 수입니다.

global-client-scheduled-thread-pool-keepalive-time

유휴 상태에서 예약된 스레드 풀에 스레드를 유지하는 시간입니다.

global-client-scheduled-thread-pool-largest-thread-count

모든 Active MQ 클라이언트에서 동시에 사용했던 예약된 풀에서 가장 많은 스레드 수.

global-client-scheduled-thread-pool-max-size

이 서버 내부에서 실행 중인 모든 ActiveMQ 클라이언트에서 사용하는 예약된 풀의 최대 스레드 수입니다.

global-client-scheduled-thread-pool-task-count

모든 Active MQ 클라이언트가 예약한 예약된 스레드 풀의 총 작업 수입니다.

global-client-thread-pool-active-count

현재 작업을 실행하는 모든 ActiveMQ 클라이언트가 사용하는 범용 풀 스레드 수입니다.

global-client-thread-pool-completed-task-count

모든 ActiveMQ 클라이언트가 실행한 범용 풀 스레드를 사용하는 작업 수입니다.

global-client-thread-pool-current-thread-count

모든 Active MQ 클라이언트에서 사용 중인 범용 풀의 현재 스레드 수입니다.

global-client-thread-pool-keepalive-time

범용 스레드 풀에서 스레드를 유휴 상태로 유지해야 하는 시간입니다.

global-client-thread-pool-largest-thread-count

모든 Active MQ 클라이언트에서 동시에 사용했던 범용 풀에서 가장 많은 스레드 수.

global-client-thread-pool-max-size

이 서버 내부에서 실행 중인 모든 ActiveMQ 클라이언트에서 사용하는 범용 풀의 최대 스레드 수입니다.

global-client-thread-pool-task-count

모든 Active MQ 클라이언트가 예약한 범용 스레드 풀의 총 작업 수입니다.

24.4. 만료 리퍼 스레드
링크 복사

단일 스레드는 서버 측에서도 대기열에서 만료된 메시지를 스캔합니다. 이 스레드는 구성 가능한 자체 우선 순위로 실행해야 하므로 스레드 풀 중 하나를 사용할 수 없습니다.

24.5. 비동기 IO
링크 복사

비동기 IO에는 기본 계층에서 이벤트를 수신하고 디스패치하는 스레드 풀이 있습니다. ArtemisMQ-AIO-poller-pool 접두사가 있는 스레드 덤프에 있습니다. JBoss EAP 메시징은 저널에서 열린 파일당 하나의 스레드를 사용합니다(일반적으로 한 개).

libaio에서 쓰기를 호출하는 데 사용되는 단일 스레드도 있습니다. 성능 문제를 일으키는 libaio에서 컨텍스트 전환을 피하도록 수행됩니다. 이 스레드는 ArtemisMQ-AIO-writer-pool 접두사가 있는 스레드 덤프에서 확인할 수 있습니다.

24.6. 클라이언트 스레드 관리
링크 복사

JBoss EAP에는 클라이언트 연결을 생성하는 데 사용되는 클라이언트 스레드 풀이 포함되어 있습니다. 이 풀은 이 장의 앞부분에서 언급한 정적 풀과 별개이며 클라이언트처럼 작동하는 경우 JBoss EAP에서 사용합니다. 예를 들어 클라이언트 스레드 풀 클라이언트는 동일한 클러스터에 있는 다른 노드와 클러스터 연결로 생성되거나 Artemis 리소스 어댑터가 JBoss EAP의 원격 인스턴스에 통합된 원격 Apache ActiveMQ Artemis 메시징 서버에 연결됩니다. 예약된 클라이언트 스레드에 대한 풀도 있습니다.

참고

JBoss EAP 7.1이 릴리스되면서 클라이언트 스레드는 활동 없이 60초 후에 시간 초과됩니다.

관리 CLI를 사용하여 클라이언트 스레드 풀 크기 설정

관리 CLI를 사용하여 클라이언트 스레드 풀과 클라이언트 예약 스레드 풀의 크기를 구성합니다. 관리 CLI를 사용하여 설정한 풀 크기는 시스템 속성을 사용하여 설정된 크기보다 우선합니다.

아래 명령은 클라이언트 스레드 풀을 설정합니다. 

/subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=POOL_SIZE)
Copy to Clipboard Toggle word wrap

이 속성에 대해 정의된 기본값은 없습니다. 특성이 정의되지 않은 경우 풀의 최대 크기는 CPU 코어 프로세서 수의 8 (8)로 결정됩니다.

현재 설정을 검토하려면 다음 명령을 사용합니다. 

/subsystem=messaging-activemq:read-attribute(name=global-client-thread-pool-max-size)
Copy to Clipboard Toggle word wrap

클라이언트 예약 스레드 풀 크기는 다음 명령을 사용하여 설정됩니다. 

/subsystem=messaging-activemq:write-attribute(name=global-client-scheduled-thread-pool-max-size,value=POOL_SIZE)
Copy to Clipboard Toggle word wrap

다음은 클라이언트 예약 스레드 풀의 현재 풀 크기를 표시합니다. 기본값은 5 입니다. 

/subsystem=messaging-activemq:read-attribute(name=global-client-scheduled-thread-pool-max-size)
Copy to Clipboard Toggle word wrap
시스템 속성을 사용하여 클라이언트 스레드 풀 크기 설정

다음 시스템 속성을 사용하여 클라이언트의 글로벌 및 글로벌 예약 스레드 풀 크기를 각각 설정할 수 있습니다.

  • activemq.artemis.client.global.thread.pool.max.size
  • activemq.artemis.client.global.scheduled.thread.pool.core.size

아래 예제와 같이 시스템 속성을 XML 구성에서 참조할 수 있습니다.

참고

관리 CLI를 사용하여 설정된 풀 크기는 시스템 속성으로 설정된 크기보다 우선합니다. 

<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>
Copy to Clipboard Toggle word wrap
자체 스레드 풀을 사용하도록 클라이언트 구성

클라이언트는 JBoss EAP에서 제공하는 풀을 사용하지 않고 자체 클라이언트 스레드 풀을 사용하도록 각 ClientSessionFactory 인스턴스를 구성할 수 있습니다. 해당 세션에서 ClientSessionFactory 를 생성한 모든 세션은 새로 생성된 풀을 사용합니다.

자체 풀을 사용하도록 ClientSessionFactory 인스턴스를 구성하려면 팩토리를 만든 직후 적절한 setter 메서드를 호출합니다. 예를 들면 다음과 같습니다. 

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(transportConfiguration);
locator.setUseGlobalPools(true);
locator.setThreadPoolMaxSize(-1);
locator.setScheduledThreadPoolMaxSize(10);
ClientSessionFactory myFactory = locator.createSessionFactory();
Copy to Clipboard Toggle word wrap

Jakarta Messaging API를 사용하는 경우 ClientSessionFactory 에서 동일한 매개변수를 설정할 수 있습니다. 예를 들면 다음과 같습니다. 

ActiveMQConnectionFactory myConnectionFactory = ActiveMQJMSClient.createConnectionFactory(url, "ConnectionFactoryName");
myConnectionFactory.setUseGlobalPools(false);
myConnectionFactory.setScheduledThreadPoolMaxSize(10);
myConnectionFactory.setThreadPoolMaxSize(-1);
Copy to Clipboard Toggle word wrap

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)
Copy to Clipboard Toggle word wrap

위의 각 명령을 실행한 후에는 관리 CLI에서 인스턴스를 다시 로드해야 한다는 메시지를 표시합니다.

25장. 중복 메시지 탐지 구성
링크 복사

발신자가 메시지를 다른 서버로 보내는 경우 메시지를 보낸 후 대상 서버 또는 연결이 실패할 수 있지만, 프로세스가 성공했음을 나타내는 발신자에 대한 응답을 보내기 전에. 이러한 상황에서는 발신자가 메시지가 의도한 수신자에게 전송되었는지 여부를 결정하는 것은 매우 어렵습니다. 발신자가 마지막 메시지를 다시 보내는 경우 중복 메시지가 주소로 보내질 수 있습니다.

애플리케이션이 중복된 메시지를 필터링하는 논리를 제공하지 않도록 JBoss EAP 메시징에서 중복 메시지 탐지를 구성할 수 있습니다.

25.1. 메시지 전송에 중복 메시지 감지 사용
링크 복사

전송된 메시지에 대해 중복된 메시지 탐지를 사용하려면 org.apache.activemq.artemis.api.core.Message.HDR_DUPLICATE_DE¢TION _ID 속성 값을 고유한 값으로 설정해야 합니다. 대상 서버에서 메시지를 받으면 _AMQ_DUPL_ID 속성이 설정된 경우 메모리 캐시를 확인하여 해당 헤더의 값이 있는 메시지를 이미 수신했는지 확인합니다. 있는 경우 이 메시지는 무시됩니다. 자세한 내용은 Duplicate ID Cache 구성을 참조하십시오.

_AMQ_DUPL_ID 속성 값은 코어 API를 사용하는 경우 type byte[] 또는 SimpleString 일 수 있습니다. Jakarta Messaging을 사용하는 경우 문자열 이어야 합니다.

다음 예제에서는 핵심 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);
Copy to Clipboard Toggle word wrap

다음 예제에서는 Jakarta Messaging 클라이언트의 속성을 설정하는 방법을 보여줍니다. 

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);
Copy to Clipboard Toggle word wrap
중요

복제된 메시지는 동일한 트랜잭션 내에 전송되면 탐지되지 않습니다 _DUPLICATE_DE¢TION_ID 속성.

25.2. 중복 ID 캐시 구성
링크 복사

서버는 각 주소로 전송되는 _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)
Copy to Clipboard Toggle word wrap

또한 캐시를 디스크에 지속하도록 구성할 수도 있습니다. 이 작업은 다음 관리 CLI 명령을 사용하여 persist-id-cache 특성을 설정하여 구성할 수 있습니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=persist-id-cache,value=true)
Copy to Clipboard Toggle word wrap

이 값을 true 로 설정하면 각 ID가 수신되는 영구 스토리지에 유지됩니다. 이 매개변수의 기본값은 true 입니다.

참고

메시지를 다시 전송해도 캐시에 저장된 이전에 전송된 메시지를 덮어쓰지 않도록 중복 ID 캐시의 크기를 큰 크기로 설정합니다.

26장. Slow 소비자 처리
링크 복사

서버 측 대기열을 사용하는 느린 소비자는 서버 성능에 큰 문제가 발생할 수 있습니다. 메시지는 소비자의 서버 측 대기열에 누적되므로 메모리 사용량이 증가합니다. 결과적으로 서버에서 페이징 모드로 전환하여 성능에 부정적인 영향을 줄 수 있습니다. 또 다른 중요한 문제는 consumer-windows-size 특성이 0 보다 크면 클라이언트의 메시지 버퍼로 전송된 메시지가 계속 사용될 때까지 대기할 수 있다는 점입니다. 메시지를 신속하게 사용하지 않는 소비자가 서버와 연결을 끊을 수 있도록 기준을 설정할 수 있습니다.

느린 소비자가 MDB인 경우 JBoss EAP 서버는 연결을 관리합니다. MDB가 연결이 끊기면 MDB가 사용 중인 큐로 메시지가 반환되고 MDB가 자동으로 다시 연결되고, 이때 메시지가 대기열의 모든 MDB에 다시 부하가 분산됩니다. 이 같은 프로세스에는 지속적 주제에 대한 MDB 수신 대기가 포함됩니다. 자카르타 메시징 소비자의 경우 속도가 느리면 연결이 끊어지고 reconnects -attempts가 -1 로 설정되었거나 0 보다 큰 경우에만 다시 연결됩니다.

구성할 수 없는 자카르타 메시징 가입자 또는 비내구성 서브스크립션이 있는 MDB의 경우 연결이 끊어져 서브스크립션이 제거됩니다. 비내구성 구독자가 다시 연결되면 복원 불가능한 새 서브스크립션이 생성되고 토픽에 전송된 새 메시지만 사용됩니다.

소비자가 느린지 여부를 결정하는 계산에서는 특정 소비자가 인정한 메시지 수만 검사합니다. 예를 들어 흐름 제어가 소비자에서 활성화되었는지 또는 소비자가 큰 메시지를 스트리밍하는지 여부는 고려하지 않습니다. 느린 소비자 탐지를 구성할 때 이 점을 유념하십시오.

느린 소비자 점검은 예약된 스레드 풀을 사용하여 수행됩니다. 소비자 탐지 속도가 느린 서버의 각 대기열은 내부 java.util.concurrent.ScheduledThreadPoolExecutor 인스턴스에서 새 항목을 생성합니다. 대기열 수가 많고 slow-consumer-check-period 가 비교적 낮은 경우 일부 검사를 실행하는 데 지연이 발생할 수 있습니다. 그러나 탐지 알고리즘에 사용된 계산의 정확성에는 영향을 미치지 않습니다. 이 스레드 풀에 대한 자세한 내용은 스레드 관리를 참조하십시오.

느린 소비자 처리는 주소 설정 기반으로 이루어집니다. address-setting 구성에 대한 자세한 내용은 주소 설정을 참조하십시오. address-setting 속성 목록은 부록을 참조하십시오. 느린 소비자를 처리하는 데는 세 가지 특성이 사용됩니다. 사용자:

slow-consumer-check-period
느린 소비자에 대해 확인하는 빈도(초)입니다. 기본값은 5 입니다.
slow-consumer-policy

느린 소비자를 식별할 때 발생하는 상황을 결정합니다. 유효한 옵션은 KILL 또는 NOTIFY 입니다 :

  • KILL 은 소비자 연결을 종료하여 동일한 연결을 사용하는 모든 클라이언트 스레드에 영향을 미칩니다.
  • NOTIFY 는 CONSUMER_SLOW 관리 알림을 클라이언트에 보냅니다.

기본값은 NOTIFY 입니다.

slow-consumer-threshold
소비자가 느리기 전에 허용되는 최소 메시지 사용률입니다. 기본값은 바인딩되지 않은 -1 입니다.

관리 CLI를 사용하여 속성의 현재 값을 읽습니다. 예를 들어 다음 명령을 사용하여 이름이 myAddress 인 address -setting에 대한 현재 slow- consumer-policy 를 읽습니다. 

/subsystem=messaging-activemq/server=default/address-setting=myAddress:read-attribute(name=slow-consumer-policy)
Copy to Clipboard Toggle word wrap

마찬가지로 다음 예제를 사용하여 동일한 slow-consumer-policy 를 설정합니다. 

/subsystem=messaging-activemq/server=default/address-setting=myAddress:write-attribute(name=slow-consumer-policy,value=<NEW_VALUE>)
Copy to Clipboard Toggle word wrap

III 부. 멀티노드 메시징 시스템 구성
링크 복사

27장. 자카르타 메시징 브리지 구성
링크 복사

JBoss EAP 메시징에는 소스 대상의 메시지를 가져와 일반적으로 다른 서버에서 대상 대상으로 보내는 Jakarta 메시징 브리지가 포함되어 있습니다.

Jakarta Messaging 브리지는 각 링크가 소스와 아래에 정의된 대상으로 구성된 대상 매핑을 지원합니다.

  • 소스는 자카르타 메시징 브리지가 메시지를 수신하는 대상을 정의합니다. 소스는 Jakarta 메시징 공급자에 대한 연결을 생성하는 연결 팩토리와 해당 공급자의 메시지 소스 대상으로 구성됩니다.
  • 대상은 자카르타 메시징 브리지가 소스에서 수신한 메시지를 보내는 대상을 정의합니다. 대상은 Jakarta 메시징 공급자에 대한 연결을 생성하는 연결 팩토리와 해당 공급자의 메시지 대상 대상으로 구성됩니다.

소스 대상이 주제인 경우 Jakarta Messaging 브리지는 서브스크립션을 생성합니다. client-id 및 subscription-name 특성이 Jakarta Messaging 브리지에 대해 구성된 경우 서브스크립션이 지속됩니다. 즉, Jakarta Messaging 브리지가 중지된 후 다시 시작하면 메시지가 누락되지 않습니다.

소스 및 대상 서버가 같은 클러스터에 없어도 되기 때문에 브리징은 한 클러스터에서 다른 클러스터, 예를 들어 WAN, 연결이 불안정할 수 있는 메시지를 안정적으로 보내는 데 적합합니다.

참고

자카르타 메시징 브리지와 코어 브리지를 혼동하지 마십시오. Jakarta Messaging 브리지를 사용하여 두 Jakarta Messaging-1.1 호환 공급자를 연결하고 Jakarta Messaging API를 사용할 수 있습니다. 구성 핵심 브리지 는 두 개의 JBoss EAP 메시징 인스턴스를 브리지하는 데 사용되며 코어 API를 사용합니다. 가능한 경우 자카르타 메시징 브리지 대신 코어 브릿지를 사용합니다.

JBoss EAP Jakarta 메시징 브리지 구성 예

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
  ...
  </server>
  <jms-bridge name="my-jms-bridge" module="org.apache.activemq.artemis" max-batch-time="100" max-batch-size="10" max-retries="1" failure-retry-interval="500" quality-of-service="AT_MOST_ONCE">
    <source destination="jms/queue/InQueue" connection-factory="ConnectionFactory">
      <source-context/>
    </source>
    <target destination="jms/queue/OutQueue" connection-factory="jms/RemoteConnectionFactory">
      <target-context>
        <property name="java.naming.factory.initial" value="org.wildfly.naming.client.WildFlyInitialContextFactory"/>
        <property name="java.naming.provider.url" value="http-remoting://192.168.40.1:8080"/>
      </target-context>
    </target>
  </jms-bridge>
  ...
</subsystem>
Copy to Clipboard Toggle word wrap

위의 예제 구성에서 Jakarta Messaging 브리지는 connection-factory 특성을 사용하여 다음 두 연결을 생성합니다.

  • 수신된 메시지의 원래 대상을 정의하는 source-context.
  • target-context - 메시지를 수신하는 대상 대상을 정의합니다.

Apache ActiveMQ Artemis 또는 Red Hat AMQ에서 제공하는 기본 구현을 사용하여 JNDI(Java Naming and Directory Interface)를 사용하여 연결 팩토리를 검색할 수 있습니다. 다른 애플리케이션 서버 또는 Jakarta 메시징 공급자의 경우 org.apache.activemq.artemis.jms.bridge.ConnectionFactoryFactory 인터페이스를 구현하여 새 구현을 제공할 수 있습니다.

관리 CLI를 사용하여 자카르타 메시징 브리지 추가

자카르타 메시징 브리지는 다음 관리 CLI 명령을 사용하여 추가할 수 있습니다. 소스 및 대상 대상은 구성에 이미 정의되어 있어야 합니다. 구성 가능한 속성의 전체 목록은 부록의 표를 참조하십시오. 

/subsystem=messaging-activemq/jms-bridge=my-jms-bridge:add(quality-of-service=AT_MOST_ONCE,module=org.apache.activemq.artemis,failure-retry-interval=500,max-retries=1,max-batch-size=10,max-batch-time=100,source-connection-factory=ConnectionFactory,source-destination=jms/queue/InQueue,source-context={},target-connection-factory=jms/RemoteConnectionFactory,target-destination=jms/queue/OutQueue,target-context={java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory,java.naming.provider.url=http-remoting://192.168.40.1:8080})
Copy to Clipboard Toggle word wrap

다음 예제와 같이 관리 CLI에서 read-resource 명령을 사용하여 Jakarta Messaging 브리지의 구성을 검토할 수 있습니다. 

/subsystem=messaging-activemq/jms-bridge=my-jms-bridge:read-resource
Copy to Clipboard Toggle word wrap

다음 예와 같이 write-attribute 를 사용하여 Jakarta Messaging 브리지에 구성을 추가합니다. 

/subsystem=messaging-activemq/jms-bridge=my-jms-bridge:write-attribute(name=ATTRIBUTE,value=VALUE)
Copy to Clipboard Toggle word wrap

관리 콘솔을 사용하여 자카르타 메시징 브리지 추가

관리 콘솔을 사용하여 다음 단계에 따라 자카르타 메시징 브리지를 추가할 수도 있습니다.

  1. 브라우저에서 관리 콘솔을 열고 구성 → 하위 시스템 → 메시징 (ActiveMQ) → JMS 브리지로 이동합니다.
  2. Add (+)(추가(+)) 버튼을 클릭하고 메시지가 표시되면 필요한 정보를 제공합니다.
  3. 완료되면 Add(추가) 를 클릭합니다.

27.1. 서비스 품질
링크 복사

JBoss EAP에서 QoS (Quality-of-service )는 메시지 사용 및 승인 방법을 결정하는 구성 가능한 속성입니다. QoS (Quality -of-service ) 및 해당 설명에 유효한 값은 아래에 있습니다. Jakarta Messaging 브리지 속성의 전체 목록은 부록의 표를 참조하십시오.

AT_MOST_ONCE

메시지는 소스에서 최대 한 번에 대상에 도달합니다. 메시지는 소스에서 사용되고 대상에 보내기 전에 승인됩니다. 따라서 소스에서 제거하거나 대상에 도착하는 사이에 오류가 발생할 경우 메시지가 손실될 수 있습니다. 이 모드가 기본값입니다.

이 모드는 지속적 및 비내구성 메시지에 모두 사용할 수 있습니다.

DUPLICATES_OK

메시지는 소스에서 사용되고 대상에 성공적으로 전송된 후 승인됩니다. 따라서 초기 메시지가 전송된 후 승인되기 전에 오류가 발생할 경우 메시지가 다시 전송될 수 있습니다.

이 모드는 지속적 및 비내구성 메시지에 모두 사용할 수 있습니다.

ONCE_AND_ONLY_ONCE

메시지는 소스에서 한 번만 대상에 도달합니다. 소스와 대상이 모두 동일한 서버 인스턴스에 있는 경우 동일한 로컬 트랜잭션에서 메시지를 보내고 승인하여 이를 수행할 수 있습니다. 소스와 대상이 다른 서버에 있는 경우 자카르타 트랜잭션에서 전송 및 소비 세션을 등록하면 됩니다. 이 트랜잭션은 브리지에서 set TransactionManager() 메서드를 사용하여 설정해야 하는 트랜잭션 관리자를 통해 제어합니다.

이 모드는 지속적 메시지에만 사용할 수 있습니다.

주의

서비스 품질 특성이 ONCE_AND_ONLY_ONCE 로 설정된 자카르타 Messaging 브리지가 배포된 서버를 종료할 때 예기치 않은 오류가 발생하지 않도록 자카르타 메시징 브리지를 사용하여 서버를 종료해야 합니다.

ONCE_AND_ONLY_ONCE 대신 DUPLICATES_OK 모드를 사용한 다음 대상에서 중복을 확인하고 폐기하여 한 번만 의미 체계를 제공할 수 있습니다. 자세한 내용은 Duplicate Message Detection 구성을 참조하십시오. 그러나 캐시는 특정 기간 동안만 유효합니다. 따라서 이 접근 방식은 ONCE_AND_ONLY_ONCE 를 사용하는 것만큼 완전하지 않지만 특정 애플리케이션 요구 사항에 따라 선택하는 것이 좋습니다.

27.2. 시간 제한 및 자카르타 메시징 브리지
링크 복사

특정 시점에 대상 또는 소스 서버를 사용할 수 없는 경우가 있습니다. 이 경우 브리지는 max-retries 값과 동일한 횟수를 다시 연결하려고 합니다. 시도 사이의 대기는 failure-retry-interval 로 설정됩니다.

주의

각 Jakarta Messaging 브리지에는 자체 max-retries 매개 변수가 있으므로 reconnect-attempts 매개 변수를 설정하지 않는 연결 팩토리를 사용하거나 0 으로 설정해야 합니다. 이렇게 하면 재연결 시간이 길어질 수 있는 잠재적인 충돌이 방지됩니다. 또한 서비스 품질이 ONCE_AND_ONLY_ONCE로 설정된 자카르타 메시징 브리지에서 참조하는 연결 팩토리는 팩토리 유형을 XA_ GENERIC, XA_ TOPIC 또는 XA_ QUEUE 로 설정해야 합니다.

27.3. RemoteConnectionFactory 예외 해결
링크 복사

자카르타 메시징 메시지 브릿지를 구성할 때 RemoteConnectionFactory 예외가 발생할 수 있습니다. 이 예외를 해결하려면 다음 단계 중 하나 또는 모두를 수행합니다.

  • 필요한 경우 Java 2 Platform Enterprise Edition (J2EE) 구성 요소, 비 J2EE 구성 요소 또는 원격 구성 요소 내에서 클라이언트 연결에 따라 URL 접두사 java:/jboss/exported 를 추가합니다.

  • 다음과 같이 연결 팩토리에 대해 두 개의 Java Naming 및 Directory Interface 이름을 사용합니다. 

    <jms-connection-factories>
 <connection-factory name="RemoteConnectionFactory">
  <connectors>
    <connector-ref connector-name="netty"/>
  </connectors>
  <entries>
    <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/> <entry name="jms/RemoteConnectionFactory"/>
  </entries>
 </connection-factory>
</jms-connection-factories>
    Copy to Clipboard Toggle word wrap

  • spring 8080 구성 파일의 다음 코드 조각을 사용합니다. 

    <jee:jndi-lookup id="jmsConnectionFactory" jndi-name="java:/ConnectionFactory" expected-type="javax.jms.ConnectionFactory" lookup-on-startup="false" />
    Copy to Clipboard Toggle word wrap
    참고

    lookup-on-startup 및 jndi-name 속성의 값은 애플리케이션에 따라 변경될 수 있습니다.

28장. 코어 브리지 구성
링크 복사

브리지의 기능은 한 대상의 메시지를 사용하여 일반적으로 다른 JBoss EAP 메시징 서버에 있는 다른 대상에 전달하는 것입니다.

소스 및 대상 서버가 같은 클러스터에 없어도 되기 때문에 브리징은 한 클러스터에서 다른 클러스터, 예를 들어 WAN 또는 인터넷 및 연결이 불안정할 수 있는 메시지를 안정적으로 보내는 데 적합합니다.

브리지는 장애 복구 기능이 내장되어 있으므로 대상 서버 연결이 네트워크 오류와 같이 손실된 경우 브리지는 다시 온라인 상태가 될 때까지 대상에 다시 연결을 시도합니다. 다시 온라인 상태가 되면 정상적으로 작업을 재개합니다.

브리지는 두 개의 개별 JBoss EAP 메시징 서버를 안정적으로 연결하는 방법입니다. 코어 브리지를 사용하는 경우 소스와 대상 서버는 모두 JBoss EAP 7 메시징 서버여야 합니다.

참고

핵심 브리지를 자카르타 메시징 브리지와 혼동하지 마십시오. 코어 브리지는 두 개의 JBoss EAP 메시징 인스턴스를 연결하는 데 사용되며 코어 API를 사용합니다. Jakarta Messaging 브리지 는 두 개의 Jakarta Messaging 2.0 호환 Jakarta Messaging 공급자를 연결하는 데 사용할 수 있으며 Jakarta Messaging API를 사용합니다. 가능한 자카르타 메시징 브리지 대신 코어 브리지를 사용하는 것이 좋습니다.

다음은 JBoss EAP 메시징 코어 브리지의 구성 예입니다. 

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <bridge name="my-core-bridge" static-connectors="bridge-connector" queue-name="jms.queue.InQueue"/>
    ...
  </server>
</subsystem>
Copy to Clipboard Toggle word wrap

이 코어 브리지는 다음 관리 CLI 명령을 사용하여 추가할 수 있습니다. 핵심 브리지를 정의할 때 큐 이름과 static- connectors 또는 discovery- group 을 정의해야 합니다. 구성 가능한 속성의 전체 목록은 부록의 표를 참조하십시오. 

/subsystem=messaging-activemq/server=default/bridge=my-core-bridge:add(static-connectors=[bridge-connector],queue-name=jms.queue.InQueue)
Copy to Clipboard Toggle word wrap

28.1. 중복 탐지를 위한 코어 브리지 구성
링크 복사

메시지를 타겟에 전달하기 전에 메시지에 아직 없는 경우 고유한 중복 ID 값을 자동으로 추가하도록 코어 브리지를 구성할 수 있습니다. 중복 메시지 탐지를 위해 코어 브리지를 구성하려면 use-duplicate-detection 특성을 기본값인 true 로 설정합니다. 

/subsystem=messaging-activemq/server=default/bridge=my-core-bridge:write-attribute(name=use-duplicate-detection,value=true)
Copy to Clipboard Toggle word wrap

29장. 클러스터 개요
링크 복사

JBoss EAP 메시징 클러스터를 사용하면 메시지 처리 로드를 공유하기 위해 JBoss EAP 메시징 서버 그룹을 함께 그룹화할 수 있습니다. 클러스터의 각 활성 노드는 자체 메시지를 관리하고 자체 연결을 처리하는 활성 JBoss EAP 메시징 서버입니다.

주의

서로 다른 버전의 JBoss EAP로 구성된 혼합 클러스터는 messaging-activemq 하위 시스템에서 지원되지 않습니다. 메시징 클러스터를 구성하는 서버는 모두 동일한 버전의 JBoss EAP를 사용해야 합니다.

클러스터는 JBoss EAP 구성 파일의 다른 노드에 대한 클러스터 연결을 선언하는 각 노드에 의해 구성됩니다. 노드가 다른 노드에 대한 클러스터 연결을 만들 때 자체와 다른 노드 간에 코어 브리지 연결을 내부적으로 생성합니다. 이 작업은 백그라운드에서 투명하게 수행됩니다. 각 노드에 대해 명시적인 브리지를 선언할 필요가 없습니다. 이러한 클러스터 연결을 통해 메시지를 클러스터의 노드 간에 전달하여 부하를 분산할 수 있습니다.

클러스터링의 중요한 부분은 서버가 클라이언트 또는 기타 서버가 최소 구성으로 연결할 수 있도록 연결 세부 정보를 브로드캐스트할 수 있는 서버 검색 입니다.

또한 이 섹션에서는 클러스터의 노드 전체에서 클라이언트 연결의 균형을 맞추기 위한 클라이언트 측 부하 분산 및 메시지 재배포 에 대해 설명합니다. 여기서 JBoss EAP 메시징은 노드 간에 메시지를 재배포하여 사용을 방지합니다.

주의

클러스터 노드가 구성되면 대칭 클러스터를 생성하기 위해 해당 구성을 다른 노드에 복사하기만 하면 됩니다.

실제로 예기치 않은 오류가 발생하지 않도록 클러스터의 각 노드는 다음 요소에 대해 동일한 구성을 공유해야 합니다.

  • cluster-connection
  • broadcast-group
  • discovery-group
  • 대기열 및 토픽을 포함한 address-settings

그러나 JBoss EAP 메시징 파일을 복사할 때는 주의해야 합니다. 메시징 데이터, 바인딩, 저널, 대규모 메시지 디렉터리를 한 노드에서 다른 노드로 복사하지 마십시오. 클러스터 노드를 처음으로 시작하고 저널 파일을 초기화하면 저널 디렉터리에 특수 식별자가 유지됩니다. 클러스터가 올바르게 구성되려면 노드에서 식별자가 고유해야 합니다.

29.1. 서버 검색
링크 복사

서버 검색은 서버가 연결 세부 정보를 전파할 수 있는 메커니즘입니다.

  • 메시징 클라이언트

    메시징 클라이언트는 클러스터의 서버가 한 번에 가동되는지에 대한 구체적인 지식 없이 클러스터의 서버에 연결할 수 있기를 원합니다.

  • 기타 서버

    클러스터의 서버는 클러스터에 있는 다른 모든 서버에 대한 사전 지식 없이 서로 클러스터 연결을 생성할 수 있어야 합니다.

이 정보 또는 클러스터 토폴로지는 클라이언트 및 클러스터 연결을 통해 다른 서버로 일반 JBoss EAP 메시징 연결을 중심으로 전송됩니다. 그러나 초기 첫 번째 연결을 설정하는 방법이 필요합니다. 이 작업은 UDP 및 JGroups와 같은 동적 검색 기술을 사용하거나 초기 커넥터의 정적 목록을 제공하여 수행할 수 있습니다.

29.1.1. 브로드캐스트 그룹
링크 복사

브로드캐스트 그룹은 서버가 네트워크를 통해 커넥터를 브로드캐스트하는 수단입니다. 커넥터 는 클라이언트 또는 기타 서버에서 서버에 연결할 수 있는 방법을 정의합니다.

브로드캐스트 그룹은 일련의 커넥터를 가져와서 네트워크에서 브로드캐스트합니다. 클러스터를 구성하는 브로드캐스트 기술에 따라 UDP 또는 JGroups를 사용하여 커넥터 쌍 정보를 브로드캐스트합니다.

브로드캐스트 그룹은 서버 구성의 messaging-activemq 하위 시스템에서 정의됩니다. JBoss EAP 메시징 서버당 여러 개의 브로드캐스트 그룹이 있을 수 있습니다.

UDP를 사용하여 방송 그룹 설정

다음은 UDP 브로드캐스트 그룹을 정의하는 메시징 서버의 구성 예입니다. 이 구성은 messaging-group 소켓 바인딩을 사용합니다. 

<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>
Copy to Clipboard Toggle word wrap

이 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.

  1. messaging-group 소켓 바인딩을 추가합니다. 

    /socket-binding-group=standard-sockets/socket-binding=messaging-group:add(interface=private,port=5432,multicast-address=231.7.7.7,multicast-port=9876)
    Copy to Clipboard Toggle word wrap

  2. 브로드캐스트 그룹을 추가합니다. 

    /subsystem=messaging-activemq/server=default/broadcast-group=my-broadcast-group:add(socket-binding=messaging-group,broadcast-period=2000,connectors=[http-connector])
    Copy to Clipboard Toggle word wrap
JGroups를 사용하여 방송 그룹 구성

아래는 UDP를 사용하는 기본 JGroups 브로드캐스트 그룹을 사용하는 브로드캐스트 그룹을 정의하는 메시징 서버의 구성 예입니다. JGroups를 브로드캐스트에 사용할 수 있으려면 jgroups-channel 을 설정해야 합니다. 

<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>
Copy to Clipboard Toggle word wrap

다음 관리 CLI 명령을 사용하여 구성할 수 있습니다. 

/subsystem=messaging-activemq/server=default/broadcast-group=my-broadcast-group:add(connectors=[http-connector],jgroups-cluster=activemq-cluster)
Copy to Clipboard Toggle word wrap
브로드캐스트 그룹 속성

아래 표에는 브로드캐스트 그룹의 구성 가능한 속성이 나열되어 있습니다.

Expand
속성설명

broadcast-period

연속 브로드캐스트 간 기간(밀리초)입니다.

커넥터

브로드캐스트할 커넥터의 이름입니다.

jGroups-channel

클러스터를 구성하기 위해 jgroups -cluster 특성과 함께 사용되는 jgroups 하위 시스템에 정의된 채널의 이름입니다. 정의되지 않은 경우 기본 채널이 사용됩니다. jgroups-channel multiplexes 그룹 통신은 jgroups-cluster 특성으로 식별됩니다.

jgroups-cluster

브로드캐스트 그룹과 검색 그룹 간의 통신에 사용되는 논리 이름입니다. 특정 브로드캐스트 그룹에서 메시지를 수신하려는 검색 그룹은 브로드캐스트 그룹에서 사용하는 동일한 클러스터 이름을 사용해야 합니다.

jgroups-stack

클러스터를 구성하는 데 사용되는 jgroups 하위 시스템에 정의된 스택의 이름입니다. 이 속성은 더 이상 사용되지 않습니다. 대신 jgroups-channel 을 사용하여 클러스터를 구성합니다. 각 jgroups-stack 은 jgroups-channel 과 이미 연결되어 있으므로 해당 채널을 사용하거나 새 jgroups-channel을 만들어 jgroups- stack 과 연결할 수 있습니다.

중요

jgroups-stack 및 jgroups-channel 이 모두 지정되면 새 jgroups-channel 이 생성되고 jgroups- stack 및 jgroups- channel과 동일한 네임스페이스에 등록됩니다. 이러한 이유로 jgroups-stack 및 jgroup-channel 이름은 고유해야 합니다.

socket-binding

브로드캐스트 그룹 소켓 바인딩입니다.

29.1.2. 검색 그룹
링크 복사

브로드캐스트 그룹은 서버에서 커넥터 정보를 브로드캐스트하는 방법을 정의하지만, 검색 그룹은 브로드캐스트 엔드포인트에서 커넥터 정보를 수신하는 방법을 정의합니다(예: UDP 멀티캐스트 주소 또는 JGroup 채널).

검색 그룹은 다른 서버에서 각 브로드캐스트마다 하나씩 커넥터 목록을 유지 관리합니다. 특정 서버에서 브로드캐스트 끝점에서 브로드캐스트 엔드포인트에서 브로드캐스트를 수신하면 해당 서버의 목록에서 해당 항목을 업데이트합니다. 시간 동안 특정 서버에서 브로드캐스트를 받지 않은 경우 목록에서 서버의 항목을 제거합니다.

검색 그룹은 JBoss EAP 메시징의 두 위치에서 사용됩니다.

  • 토폴로지를 다운로드하기 위한 초기 연결을 얻는 방법을 알 수 있도록 클러스터 연결 사용.
  • 클라이언트를 메시징하여 토폴로지를 다운로드하기 위한 초기 연결을 얻는 방법을 알 수 있습니다.

검색 그룹이 항상 브로드캐스트를 수락하지만 사용 가능한 라이브 및 백업 서버의 현재 목록은 초기 연결이 완료된 경우에만 사용됩니다. 그 결과 에서 서버 검색은 일반적인 JBoss EAP 메시징 연결을 통해 수행됩니다.

참고

각 검색 그룹은 브로드캐스트 그룹 대응과 일치하는 브로드캐스트 끝점(UDP 또는 JGroups)으로 구성해야 합니다. 예를 들어 브로드캐스트 그룹이 UDP를 사용하여 구성된 경우 검색 그룹은 UDP 및 동일한 멀티캐스트 주소를 사용해야 합니다.

29.1.2.1. 서버에서 검색 그룹 설정
링크 복사

검색 그룹은 서버 구성의 messaging-activemq 하위 시스템에서 정의됩니다. JBoss EAP 메시징 서버당 검색 그룹이 여러 개 있을 수 있습니다.

UDP를 사용하여 검색 그룹 설정

다음은 UDP 검색 그룹을 정의하는 메시징 서버의 구성 예입니다. 이 구성은 messaging-group 소켓 바인딩을 사용합니다. 

<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>
Copy to Clipboard Toggle word wrap

이 구성은 다음 관리 CLI 명령을 사용하여 수행할 수 있습니다.

  1. messaging-group 소켓 바인딩을 추가합니다. 

    /socket-binding-group=standard-sockets/socket-binding=messaging-group:add(interface=private,port=5432,multicast-address=231.7.7.7,multicast-port=9876)
    Copy to Clipboard Toggle word wrap

  2. 검색 그룹을 추가합니다. 

    /subsystem=messaging-activemq/server=default/discovery-group=my-discovery-group:add(socket-binding=messaging-group,refresh-timeout=10000)
    Copy to Clipboard Toggle word wrap
JGroups를 사용하여 검색 그룹 구성

다음은 JGroups 검색 그룹을 정의하는 메시징 서버의 구성 예입니다. 

<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>
Copy to Clipboard Toggle word wrap

다음 관리 CLI 명령을 사용하여 구성할 수 있습니다. 

/subsystem=messaging-activemq/server=default/discovery-group=my-discovery-group:add(refresh-timeout=10000,jgroups-cluster=activemq-cluster)
Copy to Clipboard Toggle word wrap
검색 그룹 속성

아래 표에는 검색 그룹의 구성 가능한 속성이 나열되어 있습니다.

Expand
속성설명

initial-wait-timeout

최초 브로드캐스트가 클러스터에 하나 이상의 노드를 제공할 때까지 대기하는 기간(밀리초)입니다.

jGroups-channel

클러스터를 구성하기 위해 jgroups -cluster 특성과 함께 사용되는 jgroups 하위 시스템에 정의된 채널의 이름입니다. 정의되지 않은 경우 기본 채널이 사용됩니다. jgroups-channel multiplexes 그룹 통신은 jgroups-cluster 특성으로 식별됩니다.

jgroups-cluster

브로드캐스트 그룹과 검색 그룹 간의 통신에 사용되는 논리 이름입니다. 특정 브로드캐스트 그룹에서 메시지를 수신하려는 검색 그룹은 브로드캐스트 그룹에서 사용하는 동일한 클러스터 이름을 사용해야 합니다.

jgroups-stack

클러스터를 구성하는 데 사용되는 jgroups 하위 시스템에 정의된 스택의 이름입니다. 이 속성은 더 이상 사용되지 않습니다. 대신 jgroups-channel 을 사용하여 클러스터를 구성합니다. 각 jgroups-stack 은 jgroups-channel 과 이미 연결되어 있으므로 해당 채널을 사용하거나 새 jgroups-channel을 만들어 jgroups- stack 과 연결할 수 있습니다.

중요

jgroups-stack 및 jgroups-channel 이 모두 지정되면 새 jgroups-channel 이 생성되고 jgroups- stack 및 jgroups- channel과 동일한 네임스페이스에 등록됩니다. 이러한 이유로 jgroups-stack 및 jgroup-channel 이름은 고유해야 합니다.

새로 고침 시간 제한

검색 그룹이 특정 서버에서 마지막 브로드캐스트를 수신한 후 대기하는 동안 기다린 후 목록에서 서버의 커넥터 쌍 항목을 제거합니다.

socket-binding

검색 그룹 소켓 바인딩입니다.

주의

위에서 설명한 JGroups 특성과 UDP별 특성은 서로 배타적입니다. 검색 그룹 구성에 하나의 집합만 지정할 수 있습니다.

29.1.2.2. 클라이언트 측에서 검색 그룹 구성
링크 복사

자카르타 메시징 또는 핵심 API를 사용하여 연결할 수 있는 서버 목록을 검색하도록 JBoss EAP 메시징 클라이언트를 구성할 수 있습니다.

자카르타 메시징을 사용하여 클라이언트 검색 구성

Jakarta Messaging을 사용하는 클라이언트는 JNDI로 관련 ConnectionFactory 를 조회할 수 있습니다. connection-factory 또는 pooled- connection-factory 의 entries 특성은 팩토리가 노출될 JNDI 이름을 지정합니다. 다음은 JNDI로 조회할 원격 클라이언트에 대해 구성된 ConnectionFactory 의 예입니다. 

<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>
Copy to Clipboard Toggle word wrap
참고

java:jboss/exported 네임스페이스에 바인딩된 JNDI 이름만 원격 클라이언트에 사용할 수 있다는 점을 기억해야 합니다. connection-factory 에 java:jboss/exported 네임스페이스에 바인딩된 항목이 있는 경우 원격 클라이언트는 java:jboss/exported 다음에 있는 텍스트를 사용하여 connection-factory 를 조회합니다. 예를 들어 RemoteConnectionFactory 는 기본적으로 java:jboss/exported/jms/RemoteConnectionFactory 에 바인딩됩니다. 즉 원격 클라이언트가 jms/RemoteConnectionFactory 를 사용하여 이 연결 팩토리를 조회합니다. pooled-connection-factory 는 원격 클라이언트에 적합하지 않기 때문에 java:jboss/exported 네임스페이스에 바인딩 된 항목이 없어야 합니다.

Jakarta Messaging 2.0 이후 기본 Jakarta Messaging 연결 팩토리는 JNDI 이름 java:comp/DefaultJMSConnectionFactory 아래 Jakarta EE 애플리케이션에서 액세스할 수 있습니다. JBoss EAP messaging-activemq 하위 시스템은 이 기본 연결 팩토리를 제공하는 데 사용되는 pooled-connection-factory 를 정의합니다. 이 pooled-connection-factory 의 매개변수 변경 사항은 JNDI 이름 java:comp/DefaultJMSConnectionFactory 에서 기본 자카르타 메시징 공급자를 찾는 자카르타 EE 애플리케이션에서 고려합니다. 다음은 *-full 및 *-full- ha 프로필에 정의된 기본 풀링된 연결 팩토리입니다. 

<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>
Copy to Clipboard Toggle word wrap
코어 API를 사용하여 클라이언트 검색 구성

코어 API를 사용하여 ClientSessionFactory 인스턴스를 직접 인스턴스화하는 경우 세션 팩토리를 생성할 때 직접 검색 그룹 매개변수를 지정할 수 있습니다. 예를 들면 다음과 같습니다. 

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();
Copy to Clipboard Toggle word wrap

DiscoveryGroupConfiguration 에서 setDiscoveryRefreshTimeout() setter 메서드를 사용하여 기본값이 10000 밀리초인 refresh-timeout 값을 설정할 수 있습니다.

DiscoveryGroupConfiguration 에서 setDiscoveryInitialWaitTimeout() setter 메서드를 사용하여 첫 번째 세션을 만들기 전에 세션 팩토리가 대기하는 시간을 결정하는 initial-wait-timeout 값을 설정할 수도 있습니다. 기본값은 10000 밀리초입니다.

29.1.3. 정적 검색
링크 복사

네트워크에서 UDP를 사용할 수 없거나 사용하지 않으려는 경우 하나 이상의 서버의 초기 목록으로 연결을 구성할 수 있습니다.

이는 모든 서버를 호스팅할 위치를 알아야 한다는 것을 의미하지는 않습니다. 이러한 서버를 신뢰할 수 있는 서버에 연결하도록 구성하고 해당 서버를 통해 전달된 연결 세부 정보를 설정할 수 있습니다.

클러스터 연결 구성

클러스터 연결의 경우 는 추가 구성이 필요하지 않습니다. 모든 커넥터가 일반적인 방식으로 정의되었는지 확인해야 합니다. 그런 다음 클러스터 연결 구성에서 이를 참조합니다.

클라이언트 연결 구성

클라이언트가 사용할 수 있는 서버의 정적 목록도 사용할 수 있습니다.

자카르타 메시징을 사용하여 클라이언트 검색 구성

Jakarta Messaging에서 정적 검색을 사용하는 권장 방법은 여러 커넥터(클러스터의 고유한 노드를 가리키는)를 사용하여 연결 팩토리를 구성하고 클라이언트가 JNDI를 사용하여 ConnectionFactory를 조회하도록 하는 것입니다. 다음은 그러한 커넥션 팩토리를 나타내는 구성 조각입니다: 

<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>
Copy to Clipboard Toggle word wrap

위의 예에서 http-connector 는 로컬 서버를 가리키는 HTTP 커넥터(<http-connector>)이며 http-node1 은 server node1 을 가리키는 HTTP 커넥터입니다. 서버 구성에서 커넥터를 구성하는 방법은 커넥터 및 수락자 섹션 을 참조하십시오.

코어 API를 사용하여 클라이언트 검색 구성

코어 API를 사용하는 경우 클러스터의 각 서버에 대해 고유한 TransportConfiguration 을 생성하여 아래 예제 코드와 같이 ServerLocator 생성을 담당하는 메서드에 전달합니다. 

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();
Copy to Clipboard Toggle word wrap

29.1.4. 기본manila 값
링크 복사

이전에는-2021:2 -defaults.xml 파일을 검토하여 시간이 많이 걸리는 기본 Manila 값을 찾아야 했습니다. 검토 편의를 위해 Red Hat은 다음과 같은 기본manila 값을 나열했습니다. 

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:org:jgroups">
    <UDP
        ip_ttl="2"
        mcast_recv_buf_size="25m"
        mcast_send_buf_size="1m"
        ucast_recv_buf_size="20m"
        ucast_send_buf_size="1m"
        port_range="0"
    />
    <TCP
        send_buf_size="640k"
        sock_conn_timeout="300"
        port_range="0"
    />
    <TCP_NIO2
        send_buf_size="640k"
        sock_conn_timeout="300"
        port_range="0"
    />
    <TCPPING port_range="0" num_discovery_runs="4"/>
    <MPING ip_ttl="2"/>
    <kubernetes.KUBE_PING port_range="0"/>
    <MERGE3
        min_interval="10000"
        max_interval="30000"
    />
    <FD max_tries="5"
        msg_counts_as_heartbeat="false"
        timeout="3000"
    />
    <FD_ALL
        interval="15000"
        timeout="60000"
        timeout_check_interval="5000"/>
    <FD_SOCK/>
    <VERIFY_SUSPECT timeout="1000"/>
    <pbcast.NAKACK2
        xmit_interval="100"
        xmit_table_num_rows="50"
    />
    <UNICAST3
        xmit_interval="100"
        xmit_table_num_rows="50"
    />
    <pbcast.STABLE
        stability_delay="500"
        desired_avg_gossip="5000"
        max_bytes="1m"
    />
    <pbcast.GMS print_local_addr="false"/>
    <UFC max_credits="2m"/>
    <MFC max_credits="2m"/>
    <FRAG2 frag_size="30k"/>
</config>
Copy to Clipboard Toggle word wrap

29.2. 서버 측 메시지 로드 밸런싱
링크 복사

클러스터의 노드 간에 클러스터 연결이 정의된 경우 JBoss EAP 메시징은 클라이언트에서 특정 노드에 도착하는 메시지를 부하 분산합니다.

메시징 클러스터 연결은 다른 노드에 일치하는 소비자가 있는지 여부에 관계없이 라운드 로빈 방식으로 메시지를 부하 분산하도록 구성할 수 있습니다. 일치하는 소비자가 있는 경우에만 다른 노드에 배포하도록 구성할 수도 있습니다. 자세한 내용은 Message Redistribution(메시지 재배포 ) 섹션을 참조하십시오.

클러스터 연결 구성

클러스터 연결은 클러스터의 노드 간에 메시지를 부하 분산할 수 있도록 클러스터로 서버를 그룹화합니다. 클러스터 연결은 cluster-connection 요소를 사용하여 JBoss EAP 서버 구성에 정의됩니다.

주의

Red Hat은 messaging-activemq 하위 시스템 내에서 하나의 cluster-connection 만 사용할 수 있도록 지원합니다.

다음은 * - 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>
Copy to Clipboard Toggle word wrap

클러스터 연결 위에 표시된 경우 "jms"로 시작하는 주소로 전송된 메시지를 부하 분산합니다. 이 클러스터 연결은 기본적으로 "jms" 하위 문자열로 시작하는 핵심 큐에 매핑되므로 모든 Jakarta Messaging 대기열과 토픽에 적용됩니다.

참고

클러스터 연결을 사용하여 패킷이 차단되고 승인 대기 중인 경우, call-timeout 특성은 예외를 발생하기 전에 응답 대기 시간을 지정합니다. 기본값은 30000 입니다. 예를 들어, 원격 자카르타 메시징 브로커가 네트워크에서 연결이 끊어지고 트랜잭션이 불완전한 경우 연결이 다시 설정될 때까지 스레드가 정지될 수 있습니다. 이 상황을 방지하려면 call-failover-timeout 속성을 call-timeout 특성과 함께 사용하는 것이 좋습니다 . 페일오버 시도 중에 호출이 수행되면 call-failover-timeout 속성이 사용됩니다. 기본값은 -1 이므로 시간 초과가 없습니다. 클라이언트 페일오버에 대한 자세한 내용은 자동 클라이언트 페일오버를 참조하십시오.

참고

또는 클러스터 연결을 통해 검색에 정적 서버 목록을 사용하려면 static-connectors 특성을 사용할 수 있습니다. 예를 들면 다음과 같습니다. 

<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>
Copy to Clipboard Toggle word wrap

이 예에서는 하나 이상의 서버를 사용할 수 있다는 것을 알고 있는 두 개의 서버가 정의되어 있습니다. 클러스터에 더 많은 서버가 있을 수 있지만 초기 연결이 이루어지면 이러한 커넥터 중 하나를 사용하여 검색할 수 있습니다.

중복 탐지를 위한 클러스터 연결 구성

클러스터 연결은 내부적으로 코어 브리지 를 사용하여 클러스터의 노드 간에 메시지를 이동합니다. 중복 메시지 탐지를 위해 클러스터 연결을 구성하려면 use-duplicate-detection 특성을 기본값인 true 로 설정합니다. 

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:write-attribute(name=use-duplicate-detection,value=true)
Copy to Clipboard Toggle word wrap
클러스터 사용자 인증 정보

클러스터 노드 간 연결을 생성하여 클러스터 연결을 구성할 때 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")
Copy to Clipboard Toggle word wrap

JBoss EAP 구성 파일의 messaging-activemq 하위 시스템에 다음 XML 내용을 추가합니다. 

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <cluster user="NewClusterUser" password="NewClusterPassword123"/>
    ...
  </server>
</subsystem>
Copy to Clipboard Toggle word wrap
주의

cluster-user 의 기본값은 ACTIVEMQ.CLUSTER.ADMIN.USER 이며 cluster-password 의 기본값은 CHANGE ME입니다. 이러한 값이 기본값에서 변경되거나 원격 클라이언트가 기본값을 사용하여 서버를 연결할 수 있어야 합니다. 기본값에서 변경되지 않으면 JBoss EAP 메시징에서 이를 탐지하고 모든 시작 시 경고를 표시합니다.

참고

cluster-credential-reference 특성을 사용하여 클러스터 암호를 설정하는 대신 인증 정보 저장소를 참조할 수도 있습니다. 

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

29.3. 클라이언트 측 로드 밸런싱
링크 복사

JBoss EAP 메시징 클라이언트 측 부하 분산을 사용하면 단일 세션 팩토리를 사용하여 생성한 후속 세션을 클러스터의 다른 노드에 연결할 수 있습니다. 이렇게 하면 세션이 클러스터의 노드에 원활히 분배되고 특정 노드에서는 축소되지 않습니다.

클라이언트 팩토리에서 사용하는 로드 밸런싱 정책을 선언하는 권장 방법은 <connection -factory> 리소스의 connection-load-balancing-policy-class- name 특성을 설정하는 것입니다. JBoss EAP 메시징은 바로 사용할 수 있는 기본 로드 밸런싱 정책을 제공하며, 자체 로드 밸런싱 정책을 구현할 수도 있습니다.

라운드 로빈

이 정책을 사용하면 첫 번째 노드를 임의로 선택한 다음 각 후속 노드를 동일한 순서로 순차적으로 선택합니다.

예를 들어 B, C, D, A, B,C,D,A,B 또는D,A,B,C, D,A,B,C, C 순서로 노드를 선택할 수 있습니다.

org.apache.activemq.artemis.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy 를 connection-load-balancing-policy-class-name 으로 사용합니다.

임의

이 정책을 사용하면 각 노드가 임의로 선택됩니다.

org.apache.activemq.artemis.api.core.client.loadbalance.RandomConnectionLoadBalancingPolicy 를 connection-load-balancing-policy-class-name 으로 사용합니다.

임의의 스티키

이 정책을 사용하면 첫 번째 노드가 임의로 선택한 다음 후속 연결에 재사용됩니다.

org.apache.activemq.artemis.api.core.client.loadbalance.RandomStickyConnectionLoadBalancingPolicy 를 connection-load-balancing-policy-class-name 으로 사용합니다.

첫 번째 요소

이 정책에서 첫 번째 또는 0번째를 사용하면 노드가 항상 반환됩니다.

org.apache.activemq.artemis.api.core.client.loadbalance.FirstElementConnectionLoadBalancingPolicy 를 connection-load-balancing-policy-class-name 으로 사용합니다.

org.apache.activemq.artemis.api.core.client.loadbalance.ConnectionLoadBalancingPolicy 인터페이스를 구현하여 자체 정책을 구현할 수도 있습니다.

29.4. 메시지 재배포
링크 복사

메시지 재배포를 사용하면 소비자가 일치하지 않는 클러스터의 다른 노드로 다시 소비자가 없는 대기열에서 메시지를 자동으로 재배포하도록 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)
Copy to Clipboard Toggle word wrap

메시지 재배포는 큐의 마지막 소비자가 종료된 직후에 시작되도록 구성하거나 큐의 마지막 소비자가 재배포하기 전에 구성 가능한 지연을 대기하도록 구성할 수 있습니다. 이는 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>
Copy to Clipboard Toggle word wrap

소비자가 종료하는 일반적인 사례이므로 재배포하기 전에 지연을 도입하는 것이 바람직하지만 다른 하나는 동일한 큐에 빠르게 생성됩니다. 이 경우 새 소비자가 곧 도착하므로 즉시 재배포하고 싶지 않을 수 있습니다.

다음은 "jms"로 시작하는 주소에 바인딩된 큐 또는 항목에 대해 redistribution -delay 를 0 으로 설정하는 address-setting 의 예입니다. 이 경우 메시지가 즉시 재배포됩니다. 

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

이 주소 설정은 다음 관리 CLI 명령을 사용하여 추가할 수 있습니다. 

/subsystem=messaging-activemq/server=default/address-setting=jms.#:add(redistribution-delay=1000)
Copy to Clipboard Toggle word wrap

29.5. 클러스터 메시지 그룹화
링크 복사

중요

이 기능은 지원되지 않습니다.

클러스터형 그룹화는 일반 메시지 그룹화 와 관련된 다른 접근 방식을 따릅니다. 클러스터에서 특정 그룹 ID가 있는 메시지 그룹은 모든 노드에 도착할 수 있습니다. 노드에서 어떤 그룹의 ID가 어떤 노드의 어떤 소비자에 바인딩되어 있는지를 결정하는 것이 중요합니다. 각 노드는 메시지 그룹이 기본적으로 도착하는 위치와 관계없이 해당 그룹 ID를 처리하는 소비자가 해당 그룹 ID를 처리하는 노드로 올바르게 라우팅하는 메시지 그룹을 담당합니다. 지정된 그룹 ID가 있는 메시지가 클러스터에서 지정된 노드에 연결된 특정 소비자에게 전송되면 소비자가 연결이 끊긴 경우에도 해당 메시지는 다른 노드로 전송되지 않습니다.

이러한 상황은 그룹화 핸들러에서 처리합니다. 각 노드에는 그룹화 핸들러가 있으며, 이 그룹화 핸들러(다른 핸들러와 함께)는 메시지 그룹을 올바른 노드로 라우팅합니다. 핸들러 그룹화에는 다음 두 가지 유형이 있습니다. LOCAL 및 REMOTE.

로컬 핸들러는 메시지 그룹에서 사용해야 하는 경로를 결정합니다. 원격 핸들러는 로컬 핸들러와 통신하고 적절하게 작동합니다. 각 클러스터는 로컬 그룹화 핸들러가 있으려면 특정 노드를 선택해야 하며 다른 모든 노드에 원격 핸들러가 있어야 합니다.

주의

메시지 그룹화를 클러스터에서 사용하는 경우 원격 그룹화 핸들러로 구성된 노드가 실패하면 중단됩니다. 원격 그룹화 핸들러에 대한 백업을 설정하는 것은 올바르지 않습니다.

메시지 그룹을 처음 수신하는 노드는 일반 클러스터 라우팅 조건(round-robin queue Availability)에 따라 라우팅 결정을 내립니다. 노드는 제안 사항을 수락하는 경우 메시지를 제안된 큐로 라우팅하는 각 그룹화 핸들러에게 이 결정을 제안합니다.

그룹화 핸들러가 제안을 거부하면 다른 경로를 제안하고 그에 따라 라우팅이 수행됩니다. 다른 노드는 모음을 따르고 메시지 그룹을 선택한 큐로 전달합니다. 메시지가 큐에 도착하면 해당 큐의 고객에게 고정됩니다.

관리 CLI를 사용하여 그룹화 핸들러를 구성할 수 있습니다. 다음 명령은 주소 news.europe.# 을 사용하여 LOCAL 그룹화 핸들러를 추가합니다. 

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

이 작업을 수행하려면 서버를 다시 로드해야 합니다. 

reload
Copy to Clipboard Toggle word wrap

아래 표에는 grouping-handler 의 구성 가능한 속성이 나열되어 있습니다.

Expand
속성설명

group-timeout

REMOTE 핸들러를 사용하면 REMOTE 에서 경로가 사용되었음을 알리는 빈도를 지정합니다. LOCAL 핸들러를 사용하면 경로를 지정한 시간에 사용하지 않으면 해당 경로가 제거되고 새 경로를 설정해야 합니다. 값은 밀리초 단위입니다.

grouping-handler-address

클러스터 연결 및 사용하는 주소에 대한 참조입니다.

Reaper-period

리퍼를 실행하여 시간 초과된 그룹 바인딩이 있는지 확인하는 빈도(로컬 핸들러에 만 유효).

timeout

처리 결정을 내릴 때까지 기다리는 시간입니다. 이 시간 초과에 도달하면 전송 중에 예외가 발생하여 엄격한 순서가 유지됩니다.

type

핸들러가 의사 결정을 수행하는 클러스터의 단일 로컬 핸들러인지 또는 로컬 핸들러와 연결된 원격 핸들러인지 여부입니다. 가능한 값은 LOCAL 또는 REMOTE 입니다.

29.5.1. 클러스터된 메시지 그룹화 모범 사례
링크 복사

클러스터형 그룹화에 대한 몇 가지 모범 사례는 다음과 같습니다.

  • 정기적으로 소비자를 생성하고 닫는 경우 소비자가 다른 노드에 균등하게 배포되도록 합니다. 일단 큐가 고정되면 해당 큐에서 고객을 제거하는 것에 관계없이 메시지가 해당 큐로 자동으로 전송됩니다.
  • 메시지 그룹이 바인딩된 큐를 제거하려면 메시지를 전송하는 세션에서 큐를 삭제해야 합니다. 이렇게 하면 다른 노드가 제거된 후 이 대기열로 메시지를 라우팅하지 않습니다.
  • 장애 조치 메커니즘으로 항상 로컬 그룹화 핸들러가 있는 노드를 복제합니다.

29.6. 메시징 클러스터 시작 및 중지
링크 복사

ActiveMQ Artemis 클러스터를 구성하도록 JBoss EAP 7.4 서버를 구성하는 경우, 클러스터 실행 중인 서버에 연결된 다른 서버 및 클라이언트가 있을 수 있습니다. 클러스터에서 실행 중인 JBoss EAP 7.4 서버를 종료하기 전에 연결된 클라이언트와 서버를 먼저 종료하는 것이 좋습니다. 서버가 모든 연결을 닫을 수 있는 충분한 시간을 제공하고 닫는 동안 오류가 발생하지 않게 하려면 병렬로 이 작업을 수행해야 합니다. ActiveMQ Artemis는 클러스터 노드의 자동 축소를 지원하지 않으며 모든 클러스터 노드가 다시 시작될 것으로 예상합니다.

서버를 시작할 때도 마찬가지입니다. 먼저 ActiveMQ Artemis 클러스터에서 JBoss EAP 7.4 서버를 시작해야 합니다. 시작이 완료되면 클러스터에 연결하는 다른 서버 및 클라이언트를 시작할 수 있습니다.

30장. 고가용성
링크 복사

고가용성은 하나 이상의 서버가 실패한 후에도 시스템이 계속 작동하도록 하는 기능입니다.

고가용성의 일부는 클라이언트 애플리케이션이 계속 작동하도록 서버 장애 발생 시 클라이언트 연결이 한 서버에서 다른 서버로 마이그레이션할 수 있는 페일오버입니다.

참고

영구 메시지 데이터만 장애 조치(failover) 후에도 유지됩니다. 영구적이지 않은 메시지 데이터는 페일오버 후 사용할 수 없습니다.

30.1. 라이브 / 백업 쌍
링크 복사

JBoss EAP 7 메시징을 사용하면 각 라이브 서버에 백업이 있는 백업 쌍으로 서버를 라이브로 연결할 수 있습니다. 라이브 서버는 클라이언트로부터 메시지를 수신하지만, 페일오버가 발생할 때까지 백업 서버가 작동하지 않습니다. 백업 서버는 하나의 라이브 서버에서만 소유할 수 있으며 패시브 모드로 유지되므로 라이브 서버의 작업을 계속할 수 있습니다.

참고

라이브 서버와 백업 서버 사이에는 일대일 관계가 있습니다. 라이브 서버에는 하나의 백업 서버만 있을 수 있으며 하나의 라이브 서버에서만 백업 서버를 소유할 수 있습니다.

실시간 서버가 충돌하거나 올바른 모드로 꺼지면 현재 패시브 모드에 있는 백업 서버가 새로운 라이브 서버가 됩니다. 새 라이브 서버가 자동 장애 복구를 허용하도록 구성된 경우 이전 라이브 서버가 백업되고 자동으로 중지되어 이전 라이브 서버에서 메시지를 다시 수신할 수 있습니다.

참고

한 쌍의 라이브/백업 서버만 배포하는 경우 백업 인스턴스가 메시지를 적극적으로 처리하지 않으므로 쌍 앞에 있는 로드 밸런서를 효과적으로 사용할 수 없습니다. 또한 JNDI 및 Undertow 웹 서버와 같은 서비스는 백업 서버에서 활성화되지 않습니다. 이러한 이유로 백업 메시징 서버로 사용되는 JBoss EAP 인스턴스에 JEE 애플리케이션을 배포하는 것은 지원되지 않습니다.

30.1.1. 저널 동기화
링크 복사

HA를 복제 저널로 구성하면 백업이 라이브 서버와 동기화될 때까지 시간이 걸립니다.

동기화가 완료되었는지 확인하려면 CLI에서 다음 명령을 제출합니다. 

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-attribute(name=synchronized-with-backup)
Copy to Clipboard Toggle word wrap

결과가 true 이면 동기화가 완료됩니다.

라이브 서버를 종료하는 것이 안전한지 확인하려면 CLI에서 다음 명령을 제출합니다. 

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:read-attribute(name=synchronized-with-live)
Copy to Clipboard Toggle word wrap

결과가 true 이면 라이브 서버를 종료하는 것이 안전합니다.

30.2. HA 정책
링크 복사

JBoss EAP 메시징은 서버를 백업하기 위한 복제 및 공유 저장소라는 두 가지 전략을 지원합니다. 서버 구성 요소의 ha-policy 특성을 사용하여 선택한 정책을 지정된 서버에 할당합니다. ha-policy 에는 4 개의 유효한 값이 있습니다.

  • replication-master
  • replication-slave
  • shared-store-master
  • shared-store-slave

위 화면과 같이 값은 서버가 데이터 복제 또는 공유 저장소 ha 정책을 사용하는지 여부와 마스터 또는 슬레이브 역할을 수행하는지 여부를 지정합니다.

관리 CLI를 사용하여 선택한 서버에 ha-policy 를 추가합니다.

참고

아래 예제에서는 standalone-full-ha 구성 프로필을 사용하여 JBoss EAP를 실행한다고 가정합니다. 

/subsystem=messaging-activemq/server=SERVER/ha-policy=POLICY:add
Copy to Clipboard Toggle word wrap

예를 들어 다음 명령을 사용하여 replication-master 정책을 기본 서버에 추가합니다. 

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add
Copy to Clipboard Toggle word wrap

replication-master 정책은 기본값으로 구성됩니다. 정책을 추가할 때 기본 구성을 재정의할 값을 포함할 수 있습니다. 관리 CLI 명령을 사용하여 현재 구성을 읽습니다. 현재 구성에서는 다음 기본 구문을 사용합니다. 

/subsystem=messaging-activemq/server=SERVER/ha-policy=POLICY:read-resource
Copy to Clipboard Toggle word wrap

예를 들어, 다음 명령을 사용하여 위에서 기본 서버에 추가된 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
    }
}
Copy to Clipboard Toggle word wrap

각 정책에 사용할 수 있는 구성 옵션에 대한 자세한 내용은 데이터 복제 및 공유 저장소 를 참조하십시오.

30.3. 데이터 복제
링크 복사

복제를 사용하면 라이브 및 백업 서버 쌍이 동일한 데이터 디렉터리를 공유하지 않으며 네트워크를 통해 모든 데이터 동기화가 수행됩니다. 따라서 라이브 서버에서 수신하는 모든 (영구) 데이터가 백업에 복제됩니다.

라이브 서버가 완전히 종료되면 백업 서버가 활성화되고 클라이언트가 백업으로 장애 조치됩니다. 이 동작은 미리 결정되므로 데이터 복제를 사용할 때 구성할 수 없습니다.

백업 서버는 먼저 교체하기 전에 먼저 라이브 서버의 모든 기존 데이터를 동기화해야 합니다. 공유 스토리지와 달리, 복제 백업은 시작 후 즉시 완전히 작동하지 않습니다. 동기화가 진행되는 데 걸리는 시간은 동기화할 데이터 양과 네트워크 속도에 따라 다릅니다. 또한 백업이 시작될 때 클라이언트가 initial-replication-sync-timeout 기간 동안 차단됩니다. 이 시간 초과가 경과하면 동기화가 완료되지 않았더라도 클라이언트는 차단 해제됩니다.

장애 조치에 성공하면 백업의 저널이 라이브 서버의 데이터보다 최신 데이터를 저장하기 시작합니다. 장애 조치를 수행하도록 원래 라이브 서버를 구성하고 다시 시작되면 라이브 서버가 될 수 있습니다. 장애 복구는 라이브 서버가 다시 온라인 상태가 되기 전에 백업과 라이브 서버 간에 데이터를 동기화합니다.

두 서버가 모두 종료된 경우 관리자는 최신 데이터가 있는 서버의 저널을 확인해야 합니다. 백업 저널에 최신 데이터가 있는 경우 해당 저널을 라이브 서버에 복사합니다. 그렇지 않으면 백업이 라이브 서버에서 오래된 저널 데이터를 복제하고 자체 저널 데이터를 삭제합니다. 라이브 서버의 데이터가 최신인 경우 작업을 수행할 필요가 없으며 정상적으로 서버를 시작할 수 있습니다.

중요

대기 시간이 길고 잠재적으로 불안정한 네트워크로 인해 데이터 센터 간에 고가용성을 위해 복제된 저널을 구성하고 사용하는 것은 권장되거나 지원되지 않습니다.

실시간 및 백업 쌍 복제는 클러스터의 일부여야 합니다. cluster-connection 구성 요소는 백업 서버가 실시간 일치를 찾는 방법을 정의합니다.

이러한 위험을 제거할 수는 없지만 복제에는 네트워크 격리의 위험을 줄이기 위해 최소 3개의 실시간/백업 쌍이 필요합니다. 3개 이상의 라이브/백업 쌍을 사용하는 경우 클러스터에서 쿼럼 투표를 사용하여 두 개의 라이브 브로커를 사용하지 않도록 할 수 있습니다.

cluster-connection 을 구성할 때 다음 세부 사항을 기억하십시오.

  • 라이브 및 백업 서버 모두 동일한 클러스터의 일부여야 합니다. 간단한 실시간/백업 복제 쌍도 클러스터 구성이 필요합니다.
  • 이 쌍의 각 서버에서 클러스터 사용자 및 암호가 일치해야 합니다.

<master> 및 <slave> 요소 모두에서 group-name 속성을 구성하여 라이브/백업 서버 쌍을 지정합니다. 백업 서버는 동일한 그룹 이름을 공유하는 라이브 서버에만 연결됩니다.

그룹 이름 사용의 예로는 세 개의 라이브 서버와 3개의 백업 서버가 있다고 가정합니다. 각 라이브 서버는 자체 백업과 연결해야 하므로 다음 그룹 이름을 할당합니다.

  • live1 및 backup1은 pair1 의 그룹 이름을 사용합니다.
  • live2 및 backup2는 pair2 의 그룹 이름을 사용합니다.
  • live3 및 backup3은 pair3 의 그룹 이름을 사용합니다.

이 예에서 server backup1 은 동일한 group-name,pair1 의 라이브 서버를 검색합니다. 이 경우 서버 live1 입니다.

공유 저장소의 경우와 마찬가지로, 라이브 서버가 중지되거나 충돌하면 복제된 백업이 활성화되고 해당 작업을 대신합니다. 특히, 라이브 서버와의 연결이 끊어지면 쌍된 백업이 활성화됩니다. 이는 임시 네트워크 문제로 인해 발생할 수 있기 때문에 문제가 될 수 있습니다. 이 문제를 해결하기 위해 쌍 백업에서는 클러스터의 다른 서버에 연결할 수 있는지 여부를 결정합니다. 절반 이상의 서버에 연결할 수 있으면 활성화됩니다. 라이브 서버와 클러스터의 다른 서버 절반 이상이 통신이 끊어지면 쌍의 백업이 대기하여 라이브 서버와 다시 연결을 시도합니다. 이렇게 하면 백업과 라이브 서버가 다른 서버도 알지 못하더라도 메시지를 처리하는 "스플릿 브레인" 상황이 발생할 위험이 줄어듭니다.

중요

이는 공유 저장소 백업과 중요한 차이점입니다. 이 백업은 활성 서버를 찾지 못하고 저널의 파일 잠금이 릴리스된 경우 백업이 활성화되고 클라이언트 요청을 제공하기 시작합니다. 또한 복제에서는 백업 서버가 보유할 수 있는 데이터가 최신 상태인지 알 수 없으므로 자동 활성화를 결정할 수 없습니다. 보유한 데이터를 사용하여 복제 백업 서버를 활성화하려면 슬레이브를 master로 변경하여 활성 서버로 구성되도록 구성을 변경해야 합니다.

30.3.1. 데이터 복제 구성
링크 복사

아래는 my-cluster 라는 클러스터와 group1 이라는 백업 그룹에 상주하는 라이브 및 백업 서버 모두에 대한 기본 구성을 보여줍니다.

아래 단계에서는 관리 CLI를 사용하여 my-cluster 라는 클러스터와 group1 이라는 백업 그룹에 상주하는 라이브 및 백업 서버 모두에 대한 기본 구성을 제공합니다.

참고

아래 예제에서는 standalone-full-ha 구성 프로필을 사용하여 JBoss EAP를 실행한다고 가정합니다.

데이터 복제를 위한 라이브 서버를 구성하기 위한 관리 CLI 명령

  1. 라이브 서버에 ha-policy 추가 

    /subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(check-for-live-server=true,cluster-name=my-cluster,group-name=group1)
    Copy to Clipboard Toggle word wrap

    check-for-live-server 특성은 클러스터 내에 다른 서버에 지정된 ID가 없는지 확인하기 위해 라이브 서버에 지시합니다. 이 속성의 기본값은 JBoss EAP 7.0에서 false입니다. JBoss EAP 7.1 이상에서는 기본값은 true 입니다.

  2. ha-policy 를 백업 서버에 추가합니다. 

    /subsystem=messaging-activemq/server=default/ha-policy=replication-slave:add(cluster-name=my-cluster,group-name=group1)
    Copy to Clipboard Toggle word wrap

  3. 공유 클러스터-커넥션 이 있는지 확인합니다.

    라이브 서버와 백업 서버 간의 적절한 통신에는 클러스터 연결이 필요합니다. 다음 관리 CLI 명령을 사용하여 동일한 cluster-connection 이 라이브 및 백업 서버에 모두 구성되어 있는지 확인합니다. 이 예제에서는 standalone - full-ha 구성 프로필에 있는 기본 cluster- connection 을 사용하며 대부분의 사용 사례에 충분해야 합니다. 클러스터 연결을 구성하는 방법에 대한 자세한 내용은 클러스터 연결 구성을 참조하십시오.

    다음 관리 CLI 명령을 사용하여 라이브 및 백업 서버가 모두 동일한 cluster-connection을 사용하고 있는지 확인합니다. 

    /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource
    Copy to Clipboard Toggle word wrap

    cluster-connection 이 있으면 출력에서 현재 구성을 제공합니다. 그렇지 않으면 오류 메시지가 표시됩니다.

모든 구성 속성에 대한 자세한 내용은 모든 복제 구성을 참조하십시오.

30.3.2. 모든 복제 설정
링크 복사

관리 CLI를 사용하여 추가한 후 정책에 구성을 추가할 수 있습니다. 이를 수행하는 명령은 아래 기본 구문을 따릅니다. 

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)
Copy to Clipboard Toggle word wrap

예를 들어 restart-backup 특성 값을 true 로 설정하려면 다음 명령을 사용합니다. 

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:write-attribute(name=restart-backup,value=true)
Copy to Clipboard Toggle word wrap

다음 표에서는 replication -master 노드 및 replication- slave 구성 요소의 HA 구성 속성을 제공합니다.

Expand
표 30.1. replication-master의 속성
속성설명

Check-for-live-server

시작할 때 동일한 서버 ID를 사용하는 다른 서버의 클러스터를 확인하도록 이 서버에 알리려면 true 로 설정합니다. JBoss EAP 7.0의 기본값은 false 입니다. JBoss EAP 7.1 이상의 기본값은 true 입니다.

cluster-name

복제에 사용되는 클러스터의 이름입니다.

group-name

설정되어 있는 경우 백업 서버는 일치하는 그룹 이름과 라이브 서버만 쌍으로 연결합니다.

initial-replication-sync-timeout

시작 복제가 동기화될 때까지 밀리초 단위로 대기하는 시간입니다. 기본값은 30000 입니다.

synchronized-with-backup

실시간 서버 및 복제 서버의 저널이 동기화되었는지를 나타냅니다.

Expand
표 30.2. replication-slave의 속성
속성설명

allow-failback

요청을 다른 위치에 배치할 때 이 서버가 자동으로 중지되는지 여부입니다. 일반적인 사용 사례는 다시 시작 또는 실패 복구 후 활성 처리를 다시 시작하도록 요청하는 라이브 서버 요청입니다. allow-failback 이 true 로 설정된 백업 서버는 클러스터에 다시 가입하고 처리를 재개하도록 요청하면 라이브 서버로 생성됩니다. 기본값은 true 입니다.

cluster-name

복제에 사용되는 클러스터의 이름입니다.

group-name

설정되어 있는 경우 백업 서버는 일치하는 그룹 이름과 라이브 서버만 쌍으로 연결합니다.

initial-replication-sync-timeout

시작 복제가 동기화될 때까지 밀리초 단위로 대기하는 시간입니다. 기본값은 30000 입니다.

max-saved-replicated-journal-size

시작 시 파일을 이동한 후 복제된 백업 서버를 다시 시작할 수 있는 횟수를 지정합니다. 최대값에 도달하면 가 다시 실패하면 서버가 영구적으로 중지됩니다. 기본값은 2 입니다.

restart-backup

실패한 상태로 인해 백업 서버가 중지되면 이 백업 서버를 다시 시작하도록 지시하려면 true 로 설정합니다. 기본값은 true 입니다.

Syncd-with-live

복제 서버의 저널이 라이브 서버와 동기화되었는지를 나타냅니다. 즉, 라이브 서버를 안전하게 종료합니다.

30.3.3. 클러스터 연결 시간 제한 방지
링크 복사

각 라이브 및 백업 쌍은 클러스터 연결을 사용하여 통신합니다. cluster- connection의 call- timeout 특성은 클러스터에서 다른 서버로 호출한 후 서버가 응답을 기다리는 시간을 설정합니다. call-timeout 의 기본값은 30초로, 대부분의 사용 사례에 충분합니다. 그러나 백업 서버가 라이브 서버에서 들어오는 복제 패킷을 처리할 수 없는 경우가 있습니다. 예를 들어, 디스크 작업 속도가 느리거나 journal- min-files 의 큰 값으로 인해 저널 파일의 초기 사전 생성에 시간이 너무 오래 걸릴 수 있습니다. 이와 같은 시간 초과가 발생하면 로그에 다음 행과 유사한 행이 표시됩니다. 

AMQ222207: The backup server is not responding promptly introducing latency beyond the limit. Replication server being disconnected now.
Copy to Clipboard Toggle word wrap
주의

위와 같은 행이 로그에 표시되면 복제 프로세스가 중지되었음을 의미합니다. 복제를 다시 시작하려면 백업 서버를 다시 시작해야 합니다.

클러스터 연결 시간 초과를 방지하려면 다음 옵션을 고려하십시오.

  • cluster -connection 의 호출 시간을 늘립니다. 자세한 내용은 클러스터 연결 구성을 참조하십시오.
  • journal-min-file의 값을 줄입니다. 자세한 내용은 지속성 구성을 참조하십시오.

30.3.4. 이전 저널 디렉토리 제거
링크 복사

백업 서버는 라이브 서버와 동기화를 시작할 때 저널을 새 위치로 이동합니다. 기본적으로 저널 디렉터리는 EAP_HOME /standalone의 data/ activemq 디렉터리에 있습니다. 도메인의 경우 각 서버에 EAP_HOME /domain/servers 아래에 자체 serverX/data/ activemq 디렉토리가 있습니다. 디렉터리의 이름은 바인딩,저널,largemessages 및 페이징 입니다. 이러한 디렉터리에 대한 자세한 내용은 지속성 구성 및 페이징 구성을 참조하십시오.

이동한 후 새 디렉토리의 이름은 oldreplica.X 로, 여기서 X 는 숫자 접미사입니다. 새 페일오버로 인해 다른 동기화가 시작되는 경우 "이동된" 디렉토리의 접미사는 1만큼 증가합니다. 예를 들어 첫 번째 동기화에서는 저널 디렉터리가 두 번째, oldreplica. 2 등과 같이 oldreplica. 1 로 이동됩니다. 원래 디렉토리는 라이브 서버에서 동기화된 데이터를 저장합니다.

기본적으로 백업 서버는 두 번 장애 조치(failing) 및 실패(failing)를 관리하도록 구성됩니다. 그런 다음 정리 프로세스가 트리거되면 oldreplica.X 디렉터리를 제거합니다. 백업 서버에서 max-saved-replicated-journal-size 특성을 사용하여 정리 프로세스를 트리거하는 장애 조치 발생 수를 변경할 수 있습니다.

참고

라이브 서버에는 max-saved-replicated-journal-size 가 2 로 설정됩니다. 이 값은 변경할 수 없습니다

30.3.5. 전용 라이브 및 백업 서버 업데이트
링크 복사

각 서버가 JBoss EAP의 자체 인스턴스에서 실행되는 전용 토폴로지에 라이브 및 백업 서버가 배포된 경우 다음 단계를 수행하여 클러스터를 원활하게 업데이트하고 다시 시작합니다.

  1. 백업 서버를 완전히 종료합니다.
  2. 라이브 서버를 완전히 종료합니다.
  3. 라이브 및 백업 서버의 구성을 업데이트합니다.
  4. 라이브 서버 시작.
  5. 백업 서버를 시작합니다.

30.3.6. 브로커의 네트워크 분리 감지
링크 복사

브로커의 네트워크 분리를 감지하려면 구성 가능한 호스트 목록을 ping할 수 있습니다. 다음 매개 변수 중 하나를 사용하여 네트워크에서 브로커의 상태를 감지하는 방법을 구성합니다.

  • network-check-NIC: InetAddress.isReachable 메서드에서 사용할 NIC(Network Interface Controller)를 사용하여 네트워크 가용성을 확인합니다.
  • network-check-period: 네트워크 상태를 확인하는 빈도를 정의하는 시간(밀리초)을 나타냅니다.
  • network-check-timeout: 네트워크 연결이 만료되기 전 대기 시간을 나타냅니다.
  • network-check-list: 네트워크 상태를 감지하기 위해 ping되는 IP 주소 목록을 나타냅니다.
  • network-check-URL-list: 네트워크 유효성 검사에 사용되는 http URI 목록을 나타냅니다.
  • network-check-ping-command: IPv4 네트워크에서 네트워크 상태를 감지하는 데 사용되는 ping 명령 및 해당 매개변수를 나타냅니다.
  • network-check-ping6-command: IPv6 네트워크에서 네트워크 상태를 감지하는 데 사용되는 ping 명령 및 해당 매개변수를 나타냅니다.

절차

  • 다음 명령을 사용하여 구성 가능한 호스트 목록을 ping하여 브로커의 네트워크 격리를 감지합니다. 

    /subsystem=messaging-activemq/server=default:write-attribute(name=<parameter-name>, value="<ip-address>")
    Copy to Clipboard Toggle word wrap

예제

IP 주소 10.0.0.1 을 ping하여 네트워크 상태를 확인하려면 다음 명령을 실행합니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=network-check-list, value="10.0.0.1")
Copy to Clipboard Toggle word wrap

30.3.7. 데이터 복제의 제한 사항: Brain 처리 분할
링크 복사

라이브 서버와 해당 백업이 동시에 활성 상태일 때 "분리" 상황이 발생합니다. 두 서버 모두 다른 서버는 인식하지 않고도 클라이언트 및 프로세스 메시지를 제공할 수 있습니다. 이 경우 라이브 서버와 백업 서버 간에 더 이상 메시지 복제가 없습니다. 두 서버 간에 네트워크 오류가 발생하는 경우 분할이 발생할 수 있습니다.

예를 들어, 라이브 서버와 네트워크 라우터 간의 연결이 끊어지면 백업 서버에서 라이브 서버와의 연결이 끊어집니다. 그러나 백업은 여전히 클러스터의 절반 이상의 서버에 연결할 수 있으므로 활성화됩니다. 활성 백업 쌍이 하나뿐이고 백업 서버가 라이브 서버에 대한 연결이 손실되는 경우에도 백업이 활성화됩니다. 두 서버가 모두 클러스터 내에서 활성 상태일 때 바람직하지 않은 두 가지 상황이 발생할 수 있습니다.

  1. 원격 클라이언트가 백업 서버로 페일오버하지만 MDB와 같은 로컬 클라이언트는 라이브 서버를 사용합니다. 두 노드 모두 완전히 다른 저널을 가지므로 분할된 블록 처리가 생성됩니다.
  2. 원격 클라이언트가 백업 서버로 이미 실패한 경우 라이브 서버에 대한 연결이 끊어졌습니다. 이전 클라이언트에서 백업을 계속 사용하는 동안 새 클라이언트가 라이브 서버에 연결되어 새 클라이언트도 분할된 씬 시나리오가 됩니다.

고객은 데이터 복제를 사용할 때 분할 블록 처리의 위험을 줄이기 위해 각 라이브 및 백업 서버 쌍 간에 신뢰할 수 있는 네트워크를 구현해야 합니다. 예를 들어 중복된 네트워크 인터페이스 카드 및 기타 네트워크 이중화를 사용합니다.

30.4. 공유 저장소
링크 복사

이러한 고가용성 스타일은 데이터 복제와 다릅니다. 라이브 및 백업 노드에서 모두 액세스할 수 있는 공유 파일 시스템이 필요하기 때문입니다. 즉, 서버 쌍은 구성에서 페이징,메시지 저널,바인딩 저널 및 대규모 메시지에 대해 동일한 위치를 사용합니다.

참고

공유 저장소 사용은 Windows에서 지원되지 않습니다. Red Hat Enterprise Linux에서 GFS2 또는 NFSv4 버전을 사용할 때 지원됩니다. 또한 GFS2는 ASYNCIO 저널 유형에서만 지원되지만 NFSv4는 ASYNCIO 및 NIO 저널 유형에서 모두 지원됩니다.

또한 클러스터의 일부가 아닌 경우에도 쌍, 실시간 및 백업에 참여하는 각 서버에는 클러스터의 일부가 아닌 경우에도 클러스터 커넥션을 정의해야 합니다. cluster-connection 은 백업 서버가 라이브 서버 및 기타 노드에 대한 존재를 알리는 방법을 정의하기 때문입니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 클러스터 연결 구성을 참조하십시오.

페일오버가 발생하고 백업 서버가 인수되면 클라이언트가 연결할 수 있기 전에 공유 파일 시스템에서 영구 스토리지를 로드해야 합니다. 이러한 고가용성 스타일은 데이터 복제와 다릅니다. 실시간 및 백업 쌍 모두에서 액세스할 수 있는 공유 파일 시스템이 필요하기 때문입니다. 일반적으로 이 네트워크는 일종의 고성능 스토리지 영역 네트워크 또는 SAN입니다. 스토리지 솔루션에는 NAS라고 하는 Network Attached Storage를 사용하지 않는 것이 좋습니다.

공유 저장소 고가용성의 이점은 라이브 노드와 백업 노드 간에 복제가 이루어지지 않는다는 것입니다. 즉, 일반 작업 중에 복제 오버헤드로 인해 성능이 저하되지 않습니다.

공유 저장소 복제의 단점은 백업 서버가 활성화할 때 공유 저장소에서 저널을 로드해야 한다는 것입니다. 이 작업은 저장소의 데이터 양에 따라 다소 시간이 걸릴 수 있다는 것입니다. 또한 JBoss EAP에서 지원하는 공유 스토리지 솔루션이 필요합니다.

정상 작동 중에 최고의 성능이 필요한 경우 고성능 SAN에 액세스하고 약간 느린 페일오버 비용을 수락하는 것이 좋습니다. 정확한 비용은 데이터의 양에 따라 달라집니다.

Ha 공유 저장소
View larger image
Ha 공유 저장소

30.4.1. 공유 저장소 구성
링크 복사

참고

아래 예제에서는 standalone-full-ha 구성 프로필을 사용하여 JBoss EAP를 실행한다고 가정합니다.

  1. ha-policy 를 Live 서버에 추가합니다. 

    /subsystem=messaging-activemq/server=default/ha-policy=shared-store-master:add
    Copy to Clipboard Toggle word wrap

  2. ha-policy 를 백업 서버에 추가합니다. 

    /subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:add
    Copy to Clipboard Toggle word wrap

  3. 공유 클러스터-커넥션 이 있는지 확인합니다.

    라이브 서버와 백업 서버 간의 적절한 통신에는 클러스터 연결이 필요합니다. 다음 관리 CLI 명령을 사용하여 동일한 cluster-connection 이 라이브 및 백업 서버에 모두 구성되어 있는지 확인합니다. 이 예제에서는 standalone - full-ha 구성 프로필에 있는 기본 cluster- connection 을 사용하며 대부분의 사용 사례에 충분해야 합니다. 클러스터 연결을 구성하는 방법에 대한 자세한 내용은 클러스터 연결 구성을 참조하십시오. 

    /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource
    Copy to Clipboard Toggle word wrap

    cluster-connection 이 있으면 출력에서 현재 구성을 제공합니다. 그렇지 않으면 오류 메시지가 표시됩니다.

공유 저장소 정책에 대한 모든 구성 속성에 대한 자세한 내용은 모든 공유 저장소 구성을 참조하십시오.

30.4.2. 모든 공유 저장소 설정
링크 복사

관리 CLI를 사용하여 정책에 구성을 추가합니다. 이를 수행하는 명령은 아래 기본 구문을 따릅니다. 

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)
Copy to Clipboard Toggle word wrap

예를 들어 restart-backup 특성 값을 true 로 설정하려면 다음 명령을 사용합니다. 

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=restart-backup,value=true)
Copy to Clipboard Toggle word wrap
Expand
표 30.3. shared-store-master 구성 요소의 특성
속성설명

failover-on-server-shutdown

정상적으로 종료될 때 이 서버가 장애 조치(failover)되도록 하려면 true 로 설정합니다. 기본값은 false 입니다.

Expand
표 30.4. 공유 저장소-슬레이브 구성 요소의 속성
속성설명

allow-failback

다른 요청이 있는 경우 해당 서버를 자동으로 중지하도록 하려면 true 로 설정합니다. 사용 사례는 일반 서버가 중지되고 해당 백업이 해당 작업을 대신한 후에 기본 서버를 다시 시작하고 서버(이전 백업)를 요청하여 작동을 중지합니다. 기본값은 true 입니다.

failover-on-server-shutdown

정상적으로 종료될 때 이 서버가 장애 조치(failover)되도록 하려면 true 로 설정합니다. 기본값은 false 입니다.

restart-backup

장애 복구 또는 축소로 인해 중지된 경우 이 서버를 다시 시작하도록 지정하려면 true 로 설정합니다. 기본값은 true 입니다.

30.5. 라이브 서버로 돌아가기 실패
링크 복사

라이브 서버가 실패하고 백업이 작업을 대신한 후 라이브 서버를 다시 시작하고 클라이언트가 다시 실패하게 할 수 있습니다.

공유 저장소의 경우 원래 라이브 서버를 다시 시작하고 프로세스 자체를 종료하여 새 라이브 서버를 종료합니다. 또는 슬레이브에서 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)
Copy to Clipboard Toggle word wrap

복제 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)
Copy to Clipboard Toggle word wrap

true 로 설정하면 활성 서버에서 nodeID를 사용하여 다른 서버를 시작하는 동안 클러스터를 검색합니다. 이를 찾으면 이 서버에 접속하여 "fail-back"을 시도합니다. 이는 원격 복제 시나리오이므로 원본 라이브 서버는 해당 데이터를 해당 ID와 실행 중인 백업과 동기화해야 합니다. 동기화되면 백업 서버를 종료하도록 요청하여 활성 처리를 대신할 수 있습니다. 이 동작을 통해 원본 라이브 서버에서 장애 조치가 있는지 여부를 확인하고 해당 작업을 수행한 서버가 실행 중인지 여부를 확인할 수 있습니다.

주의

백업으로 장애 조치가 발생한 후 실시간 서버를 다시 시작하면 check-for-live-server 특성을 true 로 설정해야 합니다. 그렇지 않은 경우 백업 서버가 실행되고 있는지 확인하지 않고 라이브 서버가 한 번에 시작됩니다. 이로 인해 live 및 backup이 동시에 실행되므로 새로 연결된 모든 클라이언트에 중복 메시지를 전달합니다.

공유 저장소의 경우 일반 서버가 종료되면 페일오버가 발생하여 다음과 같이 마스터 또는 슬레이브의 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)
Copy to Clipboard Toggle word wrap

원본 라이브 서버가 다시 가동되면 실행 중인 백업 서버가 강제로 종료되어 allow-failback 을 true 로 설정하여 원래 라이브 서버가 자동으로 인계될 수 있습니다. 

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

30.6. 공동 배치된 백업 서버
링크 복사

JBoss EAP를 사용하면 동일한 JVM에 백업 메시징 서버를 다른 라이브 서버와 함께 배치할 수도 있습니다. 예를 들어 각 라이브 서버가 다른 독립 실행형 서버에 대한 백업을 공동 배치하는 독립 실행형 서버의 간단한 노드 클러스터 2개를 예로 들 수 있습니다. 이러한 방식으로 서버를 배치할 때 공유 저장소 또는 복제된 HA 정책을 사용할 수 있습니다. 공동 배치를 위해 메시징 서버를 구성할 때 두 가지 중요한 점을 기억해야 합니다.

먼저 구성의 각 서버 요소에는 자체 원격 연결기 및 원격 어셉터 또는 http- connector 및 http- acceptor 가 필요합니다. 예를 들어, remote-acceptor 가 있는 라이브 서버는 포트 5445 에서 수신 대기하도록 구성할 수 있으며, 함께 배치된 백업 의 원격 승인자는 5446 포트를 사용합니다. 포트는 기본 socket-binding- group에 추가해야 하는 socket-binding 요소에 정의됩니다. http-acceptors 의 경우 라이브 및 공동 배치 백업이 동일한 http-listener 를 공유할 수 있습니다. 각 서버 구성에서 클러스터 관련 구성 요소는 서버에서 사용하는 원격 연결기 또는 http 연결기 를 사용합니다. 관련 구성은 다음 각 예제에 포함됩니다.

두 번째는 저널 관련 디렉터리에 대한 경로를 올바르게 구성해야 합니다. 예를 들어 공유 저장소의 공동 배치 토폴로지에서는 다른 라이브 서버에 공동 배치된 라이브 서버와 해당 백업 모두 바인딩 및 메시지 저널의 디렉터리 위치, 대용량 메시지 및 페이징 의 디렉터리 위치를 공유하도록 구성해야 합니다.

30.6.1. 공동 배치된 HA 토폴로지 수동 생성 구성
링크 복사

아래 단계에서 사용된 관리 CLI 명령 예제는 공동 배치된 토폴로지를 사용하는 간단한 두 노드 클러스터를 구성하는 방법을 보여줍니다. 예제에서는 두 개의 노드가 공동 배치된 클러스터를 구성합니다. 라이브 서버와 백업 서버는 각 노드에 운영됩니다. 노드 1 의 공동 배치 백업은 노드 2 에 공동 배치된 라이브 서버와 쌍으로 연결되며 노드 2 의 백업 서버는 노드 1 에서 라이브 서버와 쌍으로 연결됩니다. 공유 저장소와 데이터 복제 HA 정책 모두에 대한 예제가 포함되어 있습니다.

참고

아래 예제에서는 full-ha 구성 프로필을 사용하여 JBoss EAP를 실행한다고 가정합니다.

  1. HA 정책을 사용하도록 각 인스턴스에서 기본 서버를 수정합니다. 각 노드의 기본 서버는 라이브 서버가 됩니다. 다음 지침은 공유 저장소 정책 또는 데이터 복제 정책을 구성했는지에 따라 다릅니다.

    • 공유 저장소 정책에 대한 지침은 다음과 같습니다. 다음 관리 CLI 명령을 사용하여 기본 HA 정책을 추가합니다. 

      /subsystem=messaging-activemq/server=default/ha-policy=shared-store-master:add
      Copy to Clipboard Toggle word wrap

    • 데이터 복제 정책에 대한 지침: 각 노드의 기본 서버는 고유한 그룹 이름으로 구성해야 합니다. 다음 예제에서 첫 번째 명령은 노드 1 에서 실행되고 두 번째 명령은 노드 2 에서 실행됩니다. 

      /subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=group1,check-for-live-server=true)

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=group2,check-for-live-server=true)
      Copy to Clipboard Toggle word wrap

  2. 각 라이브 서버에 새 백업 서버를 공동 배치합니다.

    1. 새 서버를 JBoss EAP의 각 인스턴스에 추가하여 기본 라이브 서버와 함께 배치합니다. 새 서버는 다른 노드에 기본 서버를 백업합니다. 다음 관리 CLI 명령을 사용하여 backup 이라는 새 서버를 생성합니다. 

      /subsystem=messaging-activemq/server=backup:add
      Copy to Clipboard Toggle word wrap

    2. 다음으로 기본 HA 정책을 사용하도록 새 서버를 구성합니다. 다음 지침은 공유 저장소 정책 또는 데이터 복제 정책을 구성했는지에 따라 다릅니다.

      • 공유 저장소 정책에 대한 지침은 다음과 같습니다. 다음 관리 CLI 명령을 사용하여 HA 정책을 추가합니다. 

        /subsystem=messaging-activemq/server=backup/ha-policy=shared-store-slave:add
        Copy to Clipboard Toggle word wrap

      • 데이터 복제 정책에 대한 지침: 다른 노드에서 라이브 서버의 그룹 이름을 사용하도록 백업 서버를 구성합니다. 다음 예제에서 첫 번째 명령은 노드 1 에서 실행되며 두 번째 명령은 노드 2 에서 실행됩니다. 

        /subsystem=messaging-activemq/server=backup/ha-policy=replication-slave:add(cluster-name=my-cluster,group-name=group2)

/subsystem=messaging-activemq/server=backup/ha-policy=replication-slave:add(cluster-name=my-cluster,group-name=group1)
        Copy to Clipboard Toggle word wrap

  3. 모든 서버에 대한 디렉터리 위치를 구성합니다.

    서버가 HA에 대해 구성되면 바인딩 저널, 메시지 저널 및 대용량 메시지 디렉터리의 위치를 구성해야 합니다. 페이징을 사용하려면 페이징 디렉터리도 구성해야 합니다. 다음 지침은 공유 저장소 정책 또는 데이터 복제 정책을 구성했는지에 따라 다릅니다.

    • 공유 저장소 정책에 대한 지침은 다음과 같습니다. 노드 1에서 라이브 서버의 경로 값은 노드 2 에서 지원되는 파일 시스템과 동일한 위치를 가리켜야 합니다. 노드 2의 라이브 서버와 노드 1 의 백업에도 대해서도 마찬가지입니다.

      1. 다음 관리 CLI 명령을 사용하여 노드 1 의 디렉터리 위치를 구성합니다. 

        /subsystem=messaging-activemq/server=default/path=bindings-directory:write-attribute(name=path,value=/PATH/TO/shared/bindings-A)

/subsystem=messaging-activemq/server=default/path=journal-directory:write-attribute(name=path,value=/PATH/TO/shared/journal-A)

/subsystem=messaging-activemq/server=default/path=large-messages-directory:write-attribute(name=path,value=/PATH/TO/shared/largemessages-A)

/subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=path,value=/PATH/TO/shared/paging-A)

/subsystem=messaging-activemq/server=backup/path=bindings-directory:write-attribute(name=path,value=/PATH/TO/shared/bindings-B)

/subsystem=messaging-activemq/server=backup/path=journal-directory:write-attribute(name=path,value=/PATH/TO/shared/journal-B)

/subsystem=messaging-activemq/server=backup/path=large-messages-directory:write-attribute(name=path,value=/PATH/TO/shared/largemessages-B)

/subsystem=messaging-activemq/server=backup/path=paging-directory:write-attribute(name=path,value=/PATH/TO/shared/paging-B)
        Copy to Clipboard Toggle word wrap

      2. 다음 관리 CLI 명령을 사용하여 노드 2 의 디렉터리 위치를 구성합니다. 

        /subsystem=messaging-activemq/server=default/path=bindings-directory:write-attribute(name=path,value=/PATH/TO/shared/bindings-B)

/subsystem=messaging-activemq/server=default/path=journal-directory:write-attribute(name=path,value=/PATH/TO/shared/journal-B)

/subsystem=messaging-activemq/server=default/path=large-messages-directory:write-attribute(name=path,value=/PATH/TO/shared/largemessages-B)

/subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=path,value=/PATH/TO/shared/paging-B)

/subsystem=messaging-activemq/server=backup/path=bindings-directory:write-attribute(name=path,value=/PATH/TO/shared/bindings-A)

/subsystem=messaging-activemq/server=backup/path=journal-directory:write-attribute(name=path,value=/PATH/TO/shared/journal-A)

/subsystem=messaging-activemq/server=backup/path=large-messages-directory:write-attribute(name=path,value=/PATH/TO/shared/largemessages-A)

/subsystem=messaging-activemq/server=backup/path=paging-directory:write-attribute(name=path,value=/PATH/TO/shared/paging-A)
        Copy to Clipboard Toggle word wrap

    • 데이터 복제 정책에 대한 지침: 각 서버는 자체 디렉터리를 사용하며 다른 서버와 공유하지 않습니다. 아래 예제 명령에서 경로 위치의 각 값은 파일 시스템의 고유한 위치라고 가정합니다. 기본 위치를 사용하므로 라이브 서버의 디렉터리 위치를 변경할 필요가 없습니다. 그러나 백업 서버는 여전히 고유한 위치로 구성해야 합니다.

      1. 다음 관리 CLI 명령을 사용하여 노드 1 의 디렉터리 위치를 구성합니다. 

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

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

/subsystem=messaging-activemq/server=backup/path=large-messages-directory:write-attribute(name=path,value=activemq/largemessages-B)

/subsystem=messaging-activemq/server=backup/path=paging-directory:write-attribute(name=path,value=activemq/paging-B)
        Copy to Clipboard Toggle word wrap

      2. 다음 관리 CLI 명령을 사용하여 노드 2 의 디렉터리 위치를 구성합니다. 

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

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

/subsystem=messaging-activemq/server=backup/path=large-messages-directory:write-attribute(name=path,value=activemq/largemessages-B)

/subsystem=messaging-activemq/server=backup/path=paging-directory:write-attribute(name=path,value=activemq/paging-B)
        Copy to Clipboard Toggle word wrap

  4. 새 어셉터 및 커넥터를 백업 서버에 추가합니다.

    각 백업 서버는 http-connector 및 기본 http- listener 를 사용하는 http-acceptor 로 구성해야 합니다. 이렇게 하면 서버에서 HTTP 포트를 통해 통신을 수신하고 보낼 수 있습니다. 다음 예제에서는 http-acceptor 및 http-connector 를 백업 서버에 추가합니다. 

    /subsystem=messaging-activemq/server=backup/http-acceptor=http-acceptor:add(http-listener=default)

/subsystem=messaging-activemq/server=backup/http-connector=http-connector:add(endpoint=http-acceptor,socket-binding=http)
    Copy to Clipboard Toggle word wrap

  5. 백업 서버에 대해 cluster-connection 을 구성합니다.

    각 메시징 서버에는 적절한 통신을 위해 cluster -connection, broadcast-group 및 discovery-group 이 필요합니다. 다음 관리 CLI 명령을 사용하여 이러한 요소를 구성합니다. 

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

/subsystem=messaging-activemq/server=backup/discovery-group=dg-group1:add(jgroups-cluster=activemq-cluster)

/subsystem=messaging-activemq/server=backup/cluster-connection=my-cluster:add(connector-name=http-connector,cluster-connection-address=jms,discovery-group=dg-group1)
    Copy to Clipboard Toggle word wrap

이제 공동 배치된 서버 구성이 완료되었습니다.

30.7. 페일오버 모드
링크 복사

JBoss EAP 메시징은 다음 두 가지 유형의 클라이언트 페일오버를 정의합니다.

  • 자동 클라이언트 장애 조치
  • 애플리케이션 수준 클라이언트 장애 조치

또한 JBoss EAP 메시징은 동일한 서버에 연결의 100% 투명한 자동 재연결을 제공합니다(예: 일시적인 네트워크 문제인 경우). 이는 동일한 서버에 다시 연결되어 있으며 클라이언트 재커넥션 및 세션 재연결에서 논의된다는 점을 제외하고 장애 조치와 유사합니다.

장애 조치 중에 클라이언트가 영구 또는 임시 대기열에 있는 소비자가 있는 경우 백업 노드의 장애 조치 중에 해당 큐가 자동으로 다시 생성됩니다. 백업 노드에는 영구 대기열에 대한 지식이 없습니다.

30.7.1. 자동 클라이언트 페일오버
링크 복사

JBoss EAP 메시징 클라이언트는 클라이언트에서 연결 오류가 발생하는 경우(실시간 서버 연결) 오류가 발생할 경우 클라이언트가 실패를 감지하고 백업 서버에 다시 연결할 수 있도록 모든 라이브 및 백업 서버에 대한 정보를 수신하도록 구성할 수 있습니다. 그런 다음 백업 서버는 페일오버 전에 각 연결에 존재하는 모든 세션과 소비자를 자동으로 다시 생성하므로 사용자가 수동 재커넥션 논리를 직접 코딩하지 않아도 됩니다.

JBoss EAP 메시징 클라이언트는 Detecting Dead Connections 에 설명된 대로 client-failure-check-period 에서 지정한 시간 내에 서버에서 패킷을 수신하지 않은 경우 연결 오류를 감지합니다.

클라이언트가 할당된 시간 내에 데이터를 수신하지 않으면 연결이 실패하고 페일오버를 시도했다고 가정합니다. 운영 체제에서 소켓을 닫는 경우 서버 하드웨어가 충돌하는 대신 서버 프로세스가 종료될 수 있습니다. 클라이언트가 즉시 페일오버합니다.

JBoss EAP 메시징 클라이언트는 다양한 방법으로 라이브 백업 서버 쌍 목록을 검색하도록 구성할 수 있습니다. 예를 들어 명시적 엔드포인트를 사용하여 구성할 수 있지만 가장 일반적인 방법은 클라이언트가 먼저 클러스터에 연결할 때 클러스터 토폴로지에 대한 정보를 받는 것입니다. 자세한 내용은 Server Discovery 를 참조하십시오.

기본 HA 구성에는 클러스터 통신에 권장되는 http-connector를 사용하는 cluster- connection 이 포함됩니다. 이는 원격 클라이언트가 기본 RemoteConnectionFactory 를 사용하여 서버에 연결할 때 사용하는 http-connector 와 동일합니다. 권장되지 않지만 다른 커넥터를 사용할 수 있습니다. 고유한 커넥터를 사용하는 경우 원격 클라이언트와 클러스터 노드에서 사용하는 cluster -connection 모두 connection-factory 에 대한 구성의 일부로 포함되어 있는지 확인합니다. 커넥터 및 클러스터 연결에 대한 자세한 내용은 메시징 전송 및 클러스터 연결 구성을 참조하십시오.

주의

자카르타 메시징 클라이언트가 사용할 connection-factory 에 정의된 커넥터 는 클러스터에서 사용하는 cluster-connection 에 정의된 것과 동일해야 합니다. 그렇지 않으면 클라이언트에서 기본 라이브/백업 쌍의 토폴로지를 업데이트할 수 없으므로 백업 서버의 위치를 알 수 없습니다.

CLI 명령을 사용하여 connection -factory 및 cluster- connection 의 구성을 검토합니다. 예를 들어 RemoteConnectionFactory 라는 connection-factory 의 현재 구성을 읽으려면 다음 명령을 사용합니다. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-resource
Copy to Clipboard Toggle word wrap

마찬가지로 아래 명령은 my-cluster 라는 cluster-connection 에 대한 구성을 읽습니다. 

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource
Copy to Clipboard Toggle word wrap

자동 클라이언트 장애 조치를 활성화하려면 0이 아닌 재커넥션 시도를 허용하도록 클라이언트를 구성해야 합니다. 자세한 내용은 클라이언트 재커넥션 및 세션 재연결 을 참조하십시오. 기본적으로 장애 조치는 라이브 서버에 대해 하나 이상의 연결이 완료된 후에만 발생합니다. 즉, 클라이언트가 라이브 서버에 초기 연결하지 못하는 경우 페일오버가 발생하지 않습니다. 초기 시도에 실패하는 경우 클라이언트는 reconnect-attempts 속성에 따라 라이브 서버에 대한 연결을 재시도하고 구성된 횟수 이후에 실패합니다. 

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

이 규칙의 예외는 백업 서버 및 다른 라이브 서버가 없는 한 쌍의 라이브 서버만 있고 원격 MDB가 라이브 서버에 연결되어 있는 경우입니다. MDB에서 @ActivationConfigProperty(propertyName = "rebalanceConnections", propertyValue = "true") 를 구성한 경우 해당 연결을 다른 라이브 서버로 리밸런싱하려고 시도하고 백업에 장애 조치(failover)하지 않습니다.

초기 연결에서 오버 페일오버

클라이언트에서 첫 번째 연결이 완료된 후에 전체 토폴로지를 알지 못하므로 백업에 대해 모르는 시간이 있습니다. 이 시점에 오류가 발생하면 클라이언트는 원래 라이브 서버에만 다시 연결할 수 있습니다. 클라이언트에서 시도 횟수를 구성하려면 ClientSessionFactoryImpl 또는 ActiveMQConnectionFactory 에서 속성 initialConnectAttempts 를 설정할 수 있습니다.

또는 서버 구성에서 클라이언트에서 사용하는 연결 팩토리의 initial-connect-attempts 특성을 설정할 수 있습니다. 기본값은 0, 즉 한 번만 시도합니다. 시도 횟수가 완료되면 예외가 발생합니다. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=initial-connect-attempts,value=<NEW_VALUE>)
Copy to Clipboard Toggle word wrap
서버 복제 정보

JBoss EAP 메시징은 라이브 서버와 백업 서버 간에 전체 서버 상태를 복제하지 않습니다. 백업에서 새 세션이 자동으로 다시 생성되면 해당 세션 중에 전송되거나 승인된 메시지에 대한 지식은 없습니다. 페일오버 시점에 진행 중인 모든 전송 또는 승인이 손실될 수 있습니다.

JBoss EAP 메시징은 전체 서버 상태를 복제함으로써 이론적으로 100% 투명한 페일오버를 제공하여 메시지나 감사가 손실되지 않도록 할 수 있었습니다. 그러나 이 작업을 수행하는 것은 대기열 및 세션을 포함하여 전체 서버 상태를 복제하는 데 큰 비용이 듭니다. 이를 위해서는 전체 서버 상태 시스템의 복제가 필요합니다. 즉 일관된 복제 상태를 보장하기 위해 실시간 서버의 모든 작업을 정확히 동일한 글로벌 복제 서버에 복제해야 합니다. 여러 스레드가 라이브 서버 상태를 동시에 변경하는 것을 고려하는 것은 고성능이고 확장 가능한 방식으로는 매우 어렵습니다.

가상 신디온과 같은 기술을 사용하여 전체 상태 시스템 복제를 제공할 수 있지만, 제대로 확장되지 않고 모든 작업을 단일 스레드로 직렬화하여 동시성이 크게 줄어듭니다. 잠금 상태 복제 또는 스레드 스케줄링 복제와 같은 다중 스레드 활성 복제 기법이 있지만 이는 Java 수준에서 달성하기가 매우 어렵습니다.

결과적으로 100% 투명한 페일오버를 위해 성능과 동시성을 줄일 필요가 없었습니다. 100% 투명한 페일오버가 없어도 중복 탐지와 트랜잭션 재시도를 사용하여 실패하는 경우에도 한 번만 간편하게 제공할 수 있습니다. 그러나 클라이언트 코드에 100% 투명하지는 않습니다.

30.7.1.1. 페일오버 중 차단 호출 처리
링크 복사

클라이언트 코드가 서버에 대한 호출을 차단하는 경우, 즉, 페일오버 중에 새 세션에 진행 중인 호출에 대한 정보가 없습니다. 차단된 호출은 영속적으로 중단될 수 있으며, 전달되지 않을 응답을 기다립니다.

이를 방지하기 위해 JBoss EAP 메시징은 장애 조치 시 진행 중인 모든 차단 호출을 차단 해제합니다. javax.jms.JMSException, Jakarta Messaging을 사용하는 경우 또는 코어 API를 사용하는 경우 오류 코드 ActiveMQException.UNBLOCKED를 사용하여 ActiveMQException.UNBLOCKED 가 있는 ActiveMQException. 클라이언트 코드에서 이 예외를 감지하고 필요한 경우 작업을 다시 시도합니다.

unblocked 메서드가 commit() 또는 prepare() 호출인 경우, 코어 API를 사용하는 경우 트랜잭션이 자동으로 롤백되고 JBoss EAP 메시징에서 javax.jms.TransactionRolledBackException, Jakarta Messaging을 사용하는 경우 오류 코드 ActiveMQException.TRANSACTION_ROLLED_BACK 가 있는 ActiveMQException이 발생합니다.

30.7.1.2. 트랜잭션을 사용하여 페일오버 처리
링크 복사

세션이 트랜잭션 중이고 현재 트랜잭션에서 메시지가 이미 전송되거나 승인된 경우 서버에서 장애 조치 중에 메시지 또는 승인이 손실되었는지 확인할 수 없습니다.

결과적으로 트랜잭션은 롤백 전용으로 표시되며, 코어 API를 사용하는 경우 javax.jms.TransactionRolledBackException, 즉 오류 코드 ActiveMQException. TRANSACTION_ROLLED_BACK가 발생하게 됩니다. 코어 API를 사용하는 경우 오류 코드 ActiveMQException.TRANSACTION_ROLLED_BACK 가 있는 ActiveMQException.

주의

이 규칙의 주의 사항은 XA를 자카르타 메시징을 통해 또는 핵심 API를 통해 사용할 때입니다. 2단계 커밋을 사용하고 prepare() 가 이미 호출된 경우 롤백하면 HeuristicMixedException 이 발생할 수 있습니다. 이로 인해 커밋에 XAException.XA_RETRY 예외가 발생합니다. 이는 트랜잭션 관리자가 나중에 커밋을 다시 시도해야 한다는 것을 알립니다. 부작용으로 인해 지속되지 않는 메시지가 손실됩니다. 이 문제가 발생하지 않도록 하려면 XA를 사용할 때 영구 메시지를 사용해야 합니다. prepare() 가 호출되기 전에 서버에 플러시되므로 이 문제는 문제가 되지 않습니다.

사용자가 예외를 감지하고 필요에 따라 클라이언트 측 로컬 롤백 코드를 수행합니다. 이미 롤백되었으므로 세션을 수동으로 롤백할 필요가 없습니다. 사용자는 동일한 세션에서 트랜잭션 작업을 다시 시도할 수 있습니다.

커밋 호출이 실행될 때 페일오버가 발생하면 이전에 설명한 대로 서버는 응답이 반환되지 않으므로 호출 차단을 해제하여 중지를 방지합니다. 이 경우 클라이언트가 오류가 발생하기 전에 실시간 서버에서 트랜잭션 커밋이 실제로 처리되었는지 여부를 쉽게 확인할 수 없습니다.

참고

XA가 Jakarta Messaging 또는 코어 API를 통해 사용되는 경우 XAException.XA_RETRY 가 throw됩니다. 이는 트랜잭션 관리자에게 특정 시점에 재시도가 수행되어야 함을 알리는 것입니다. 나중에 트랜잭션 관리자가 커밋을 다시 시도합니다. 원래 커밋이 발생하지 않은 경우 계속 존재하며 커밋됩니다. 트랜잭션 관리자가 경고를 기록할 수 있지만 커밋된 것으로 가정됩니다.

이를 해결하기 위해 클라이언트는 트랜잭션에서 중복 탐지를 활성화하고 호출이 차단 해제된 후 트랜잭션 작업을 다시 시도할 수 있습니다. 서버에 탐지를 구성하는 방법에 대한 자세한 내용은 메시지 탐지 중복 을 참조하십시오. 실제로 페일오버 전에 트랜잭션이 라이브 서버에 커밋된 경우 중복 탐지는 트랜잭션에 있는 지속적 메시지를 무시하여 트랜잭션 재시도 시 두 번 이상 전송되지 않도록 합니다.

30.7.1.3. 연결 오류 알림 받기
링크 복사

Jakarta Messaging은 연결 실패 비동기 알림( java.jms.ExceptionListener )을 전송하는 표준 메커니즘을 제공합니다. 이 수업에 대한 자세한 내용은 Jakarta Messaging javadoc 를 참조하십시오. 또한 핵심 API는 org.apache.activemq.artemis.core.client.SessionFailureListener 클래스의 형태로 유사한 기능을 제공합니다.

연결이 성공적으로 실패했는지 여부에 관계없이 ExceptionListener 또는 SessionFailureListener 인스턴스는 연결 실패 시 JBoss EAP에서 항상 호출됩니다. 그러나 SessionfailureListener 의 connectionFailed() 또는 다음 중 하나일 javax.jms.JMSException의 error 코드에 전달된 failedOver 플래그의 값을 검사하여 재연결 또는 재연결이 발생했는지 확인할 수 있습니다.

JMSException 오류 코드

Expand
오류 코드설명

페일오버

페일오버가 발생했으며 성공적으로 다시 연결 또는 재연결되었습니다.

연결 끊기

페일오버가 발생하지 않았으며 연결이 끊어졌습니다.

30.7.2. 애플리케이션 레벨 페일오버
링크 복사

경우에 따라 자동 클라이언트 페일오버를 원하지 않을 수 있으며 연결 오류를 직접 처리하고 자체 장애 처리기에서 직접 직접 재커넥션 논리를 코딩하는 것을 선호할 수 있습니다. 페일오버는 사용자 애플리케이션 수준에서 처리되므로 이를 애플리케이션 수준 장애 조치(failover)로 정의합니다.

Jakarta Messaging을 사용하는 경우 애플리케이션 수준 페일오버를 구현하려면 Jakarta Messaging 연결에 ExceptionListener 클래스를 설정합니다. 연결 오류가 감지되는 경우 JBoss EAP 메시징에서 ExceptionListener 를 호출합니다. ExceptionListener 에서는 이전 Jakarta Messaging 연결을 닫고 JNDI에서 새로운 연결 팩토리 인스턴스를 찾고 새 연결을 생성할 수 있습니다.

코어 API를 사용하는 경우 절차가 매우 유사합니다. 핵심 ClientSession 인스턴스에 FailureListener 를 설정합니다.

30.8. 데드 커넥션 감지
링크 복사

이 섹션에서는 TTL(연결 시간)에 대해 설명하고, JBoss EAP 메시징에서 리소스를 완전히 닫지 않고 종료한 충돌한 클라이언트 및 클라이언트를 처리하는 방법을 설명합니다.

서버에서 Dead 연결 리소스 정리

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();
   }
}
Copy to Clipboard Toggle word wrap

다음은 제대로 작동하는 자카르타 메시징 클라이언트 애플리케이션의 예입니다. 

Connection jmsConnection = null;

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

   jmsConnection = jmsConnectionFactory.createConnection();

   ... do some stuff with the connection...
}
finally {
   if (connection != null) {
      connection.close();
   }
}
Copy to Clipboard Toggle word wrap

안타깝게도 클라이언트가 충돌하여 리소스를 정리할 기회가 없는 경우가 있습니다. 이 경우 서버 측 리소스가 서버에 중단될 수 있습니다. 이러한 리소스가 제거되지 않으면 서버에서 리소스 누수가 발생하고 시간이 지남에 따라 서버에 메모리 또는 기타 리소스가 부족해질 수 있습니다.

배달되지 않은 클라이언트 리소스를 정리하는 경우 클라이언트와 서버 간에 네트워크가 실패하고 다시 돌아와 클라이언트가 다시 연결할 수 있다는 사실을 알고 있어야 합니다. JBoss EAP는 클라이언트 재커넥션을 지원하므로 너무 빨리 "데드" 서버 측 리소스를 정리하지 않아야 합니다. 그렇지 않으면 클라이언트가 서버에서 이전 세션을 다시 연결하고 다시 얻을 수 없게 됩니다.

JBoss EAP는 이 모든 구성 가능한. ClientSessionFactory가 구성된 각 ClientSessionFactory, Time-To-Live 또는 TTL에 대해 속성을 사용하여 클라이언트에서 데이터가 없을 때 서버에서 연결을 밀리초 단위로 활성 상태로 유지하는 기간을 설정할 수 있습니다. 클라이언트는 서버가 연결을 종료하지 못하도록 주기적으로 "ping" 패킷을 자동으로 전송합니다. 서버가 TTL 시간 동안 연결 시 패킷을 받지 않으면 해당 연결과 관련된 서버의 모든 세션을 자동으로 종료합니다.

Jakarta Messaging을 사용하는 경우 연결 TTL은 ActiveMQConnectionFactory 인스턴스의 ConnectionTTL 속성에 의해 정의되거나 서버 측의 JNDI로 직접 Jakarta Messaging 연결 팩토리 인스턴스를 배포하는 경우 connectionTtl 매개 변수를 사용하여 xml 구성에서 지정할 수 있습니다.

http-connector 와 같은 네트워크 기반 연결의 ConnectionTTL 기본값은 60000 입니다(예: 1분). 내부 연결의 연결 TTL 기본값(예: in-vm 연결)은 -1 입니다. ConnectionTTL 의 값 -1 은 서버가 서버 측의 연결이 시간 초과되지 않음을 의미합니다.

클라이언트가 자체 연결 TTL을 지정하지 않도록 하려면 서버 측에 전역 값을 설정할 수 있습니다. 이 작업은 서버 구성에 connection-ttl-override 특성을 지정하여 수행할 수 있습니다. connection-ttl-override 의 기본값은 -1 이므로 클라이언트가 자체 값을 사용할 수 있게 합니다.

코어 세션 또는 자카르타 메시징 연결 닫기

모든 핵심 클라이언트 세션 및 Jakarta Messaging 연결은 사용을 완료하면 항상 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)
Copy to Clipboard Toggle word wrap

Jakarta Messaging을 사용하는 경우 경고에는 클라이언트 세션이 아닌 Jakarta Messaging 연결이 포함됩니다. 또한 로그는 닫지 않은 자카르타 메시징 연결 또는 코어 클라이언트 세션이 인스턴스화된 정확한 코드 행을 알려줍니다. 이렇게 하면 코드의 오류를 찾아 적절하게 수정할 수 있습니다.

클라이언트 측에서 오류 감지

클라이언트가 서버에서 데이터를 수신하는 한 연결은 활성 상태로 간주됩니다. 클라이언트에서 client-failure-check-period 밀리초 패킷을 수신하지 못하면 연결이 실패하고 페일오버를 시작하거나 클라이언트 구성 방법에 따라 Jakarta Messaging을 사용하는 경우 FailureListener 인스턴스 또는 ExceptionListener 인스턴스를 호출합니다.

Jakarta Messaging을 사용하는 경우 이 동작은 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
Copy to Clipboard Toggle word wrap

비동기 연결 실행을 비활성화하려면 매개 변수 async-connection-execution-enabled 를 false로 설정합니다. 기본값은 true입니다.

30.9. 클라이언트 재커넥션 및 세션 재연결
링크 복사

클라이언트와 서버 간의 연결에서 오류가 감지되는 경우 서버에 자동으로 다시 연결하거나 다시 연결하도록 JBoss EAP 메시징 클라이언트를 구성할 수 있습니다.

투명한 세션 다시 첨부

임시 네트워크 중단과 같은 일시적인 원인으로 인해 오류가 발생하고 대상 서버가 다시 시작되지 않은 경우 클라이언트에서 connection-ttl 값보다 많은 경우 세션이 여전히 서버에 존재합니다. Detecting Dead Connections 를 참조하십시오.

이 시나리오에서 재연결할 때 JBoss EAP는 서버 세션에 클라이언트 세션을 자동으로 다시 연결합니다. 100% 투명하게 수행되며 클라이언트는 아무 일도 없던 것처럼 정확하게 계속할 수 있습니다.

JBoss EAP 메시징 클라이언트는 명령을 서버에 보낼 때 전송된 각 명령을 메모리 내 버퍼에 저장합니다. 연결이 실패하고 클라이언트가 재연결 프로토콜의 일부로 동일한 서버에 다시 연결을 시도하면 서버는 클라이언트가 성공적으로 수신한 마지막 명령의 id를 클라이언트에 제공합니다.

클라이언트가 페일오버 전에 수신한 것보다 많은 명령을 전송한 경우 클라이언트와 서버가 상태를 조정할 수 있도록 버퍼에서 전송된 명령을 다시 재생할 수 있습니다.

이 버퍼의 크기(바이트)는 confirmationWindowSize 속성에 의해 설정됩니다. 서버가 확인WindowSize 명령 바이트를 수신하고 처리하면 클라이언트에 명령 확인을 다시 보내 클라이언트가 버퍼의 공간을 확보할 수 있습니다.

서버에서 Jakarta Messaging 서비스를 사용하여 Jakarta Messaging 연결 팩토리 인스턴스를 JNDI로 로드하는 경우 선택한 connection-factory 의 confirmation-window-size 특성을 설정하여 서버 구성에서 이 속성을 구성할 수 있습니다. Jakarta Messaging을 사용하지만 JNDI를 사용하지 않는 경우 적절한 setter 방법을 사용하여 ActiveMQConnectionFactory 인스턴스에서 이러한 값을 직접 설정할 수 있습니다. setConfirmationWindowSize. 코어 API를 사용하는 경우 ServerLocator 인스턴스에 setConfirmationWindowSize 메서드도 노출됩니다.

verifyWindowSize 를 기본값인 -1 로 설정하면 버퍼링을 비활성화하고 재연결이 발생하지 않도록 하여 재연결을 강제 실행합니다.

세션 재커넥션

또는 충돌 후 서버가 다시 시작되었거나 중지되었을 수 있습니다. 이러한 경우 세션이 서버에 더 이상 존재하지 않으므로 100% 투명하게 다시 연결할 수 없습니다.

이 경우 JBoss EAP는 자동으로 연결을 다시 연결하고 클라이언트의 세션 및 소비자에 해당하는 서버에서 세션과 소비자를 다시 생성합니다. 이 프로세스는 백업 서버로 장애가 발생했을 때 발생하는 절차와 정확히 동일합니다.

클라이언트 재커넥션은 코어 브리지와 같은 구성 요소에서도 내부적으로 사용되므로 대상 서버에 다시 연결할 수 있습니다.

자동 클라이언트 장애(Automatic Client Failover ) 섹션을 참조하여 재연결 중에 트랜잭션 및 트랜잭션되지 않은 세션이 재연결되는 방식과 한 번만 제공 보장을 유지 관리하기 위해 수행해야 하는 사항에 대해 완벽하게 이해할 수 있습니다.

재커넥션 속성 구성

클라이언트 재커넥션은 다음 속성을 설정하여 구성됩니다.

  • retryInterval. 이 선택적 매개 변수는 대상 서버에 대한 연결이 실패한 경우 후속 재연결 시도 간격(밀리초)을 설정합니다. 기본값은 2000 밀리초입니다.

  • retryIntervalMultiplier. 이 선택적 매개 변수는 마지막 재시도 이후 시간을 다음 재시도에 계산한 후 에 적용할 승수를 설정합니다. 이렇게 하면 재시도 시도 간에 지수 백오프를 구현할 수 있습니다.

    예를 들어 retryInterval 을 1000 ms로 설정하고 retryIntervalMultiplier를 2.0 으로 설정하면 첫 번째 재연결 시도가 실패하면 클라이언트는 1000 ms를 기다린 다음 이후 다시 연결 시도 사이에 4000 ms를 기다립니다.

    기본값은 1.0 이므로 각 재연결 시도는 동일한 간격으로 공백이 지정됩니다.

  • maxRetryInterval. 이 선택적 매개변수는 사용할 최대 재시도 간격을 설정합니다. retryIntervalMultiplier 를 설정할 때 후속 재시도 횟수가 기하급수적으로 큰 값으로 증가할 수 있습니다. 이 매개변수를 설정하면 해당 값에 대한 상한을 설정할 수 있습니다. 기본값은 2000 밀리초입니다.
  • reconnectAttempts. 이 선택적 매개변수는 포기 및 종료하기 전에 수행할 총 재연결 시도 횟수를 설정합니다. 값 -1 은 시도 횟수를 나타냅니다. 기본값은 0입니다.

클라이언트에서 Jakarta Messaging 및 JNDI를 사용하여 Jakarta Messaging 연결 팩토리 인스턴스를 조회하는 경우 JNDI 컨텍스트 환경에서 이러한 매개변수를 지정할 수 있습니다. 예를 들어 jndi.properties 파일은 다음과 같을 수 있습니다. 

java.naming.factory.initial = ActiveMQInitialContextFactory
connection.ConnectionFactory=tcp://localhost:8080?retryInterval=1000&retryIntervalMultiplier=1.5&maxRetryInterval=60000&reconnectAttempts=1000
Copy to Clipboard Toggle word wrap

Jakarta Messaging을 사용 중이지만 Jakarta Messaging 연결 팩토리를 직접 인스턴스화하는 경우 ActiveMQConnectionFactory 에서 적절한 setter 메서드를 사용하여 즉시 매개변수를 지정할 수 있습니다.

코어 API를 사용하고 ServerLocator 인스턴스를 직접 인스턴스화하는 경우 ServerLocator 를 만든 직후에 적절한 setter 메서드를 사용하여 매개변수를 지정할 수도 있습니다.

클라이언트가 다시 연결하지만 서버에서 세션을 더 이상 사용할 수 없는 경우, 예를 들어 서버가 다시 시작되었거나 시간 초과된 경우 클라이언트가 다시 연결할 수 없으며 연결 또는 세션에 등록된 ExceptionListener 또는 FailureListener 인스턴스가 호출됩니다.

ExceptionListeners 및 SessionFailureListeners

클라이언트가 다시 연결하거나 다시 연결하면 등록된 Jakarta Messaging ExceptionListener 또는 코어 API SessionFailureListener 가 호출됩니다.

31장. 리소스 어댑터
링크 복사

자카르타 커넥터 리소스 어댑터를 사용하면 애플리케이션이 모든 메시징 공급자와 통신할 수 있습니다. MDB 및 기타 Jakarta Enterprise Bean과 같은 Jakarta EE 구성 요소와 서블릿이 메시지를 보내거나 받는 방법을 구성합니다.

31.1. 통합 Artemis 리소스 어댑터 정보
링크 복사

JBoss EAP 7에는 pooled-connection-factory 요소를 사용하여 리소스 어댑터의 아웃바운드 및 인바운드 연결을 구성하는 통합 Artemis 리소스 어댑터가 포함되어 있습니다.

아웃바운드 연결

아웃바운드 커넥션은 pooled-connection-factory 요소를 사용하여 정의되며, 이 요소는 Jakarta Enterprise Beans 및 서블릿에서 대기열 또는 토픽에서 메시지를 보내고 메시지를 받는 데 사용됩니다. 연결 팩토리에서 생성된 연결은 애플리케이션 서버 범위에서 생성되므로 다음과 같은 애플리케이션 서버 기능을 사용할 수 있습니다.

  • 연결 풀링
  • 애플리케이션 서버에서 정의한 보안 도메인을 사용한 인증
  • 트랜잭션 관리자를 사용하여 XA 트랜잭션에 참여

이는 InVmConnectionFactory 또는 RemoteConnectionFactory 와 같은 기본 연결 팩토리에서 이러한 기능을 사용할 수 없으므로 pooled-connection -factory 의 주요 차이점입니다. 또한 pooled-connection-factory 를 사용하여 정의된 연결 팩토리에서는 외부 독립 실행형 Jakarta Messaging 클라이언트에서 JNDI를 사용하여 조회를 수행할 수 없습니다.

인바운드 연결

인바운드 연결은 대기열 또는 주제에서 메시지를 받는 데 MDB(메시지 기반 빈)에서만 사용됩니다. MDB는 대기열 또는 토픽에서 수신 대기하는 상태 비저장 세션 빈입니다. 메시지를 대기열 또는 토픽으로 전송할 때 호출되는 public onMessage(Message message) 메서드를 구현해야 합니다. Artemis 리소스 어댑터는 대기열 또는 항목에서 메시지를 수신하여 onMessage(Message 메시지) 메서드에 전달합니다. 이를 위해 통합된 Artemis 서버의 위치 및 몇 가지 추가 요소를 정의하는 인바운드 연결을 구성합니다.

각 MDB 세션 빈은 클라이언트 스레드 풀의 스레드를 사용하여 대상의 메시지를 사용합니다. 최대 풀 크기가 정의되지 않은 경우 CPU 코어 프로세서 수의 8 (8) 배로 결정됩니다. 테스트 모음과 같이 많은 MDB 세션이 있는 시스템의 경우 스레드가 고갈될 수 있으며 MDB가 풀에서 자유 스레드를 대기하도록 할 수 있습니다. 관리 CLI를 사용하여 클라이언트 스레드 풀의 최대 풀 크기를 늘릴 수 있습니다. 다음 명령은 최대 클라이언트 스레드 풀 크기를 128 으로 설정합니다. 

/subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=128)
Copy to Clipboard Toggle word wrap

클라이언트 스레드 풀 크기를 구성하는 방법에 대한 자세한 내용은 클라이언트 스레드 관리를 참조하십시오. MDB에 대한 자세한 내용은 Message Driven Beans in Developing Jakarta Enterprise Beans for JBoss EAP를 참조하십시오.

31.2. 원격 연결을 위한 통합 Artemis 리소스 어댑터 사용
링크 복사

JBoss EAP에는 통합된 ActiveMQ Artemis 메시징 서버에 연결할 수 있는 리소스 어댑터가 포함되어 있습니다. 기본적으로 messaging -activemq 하위 시스템에 정의된 pooled-connection- factory 는 어댑터를 사용하여 연결을 만듭니다. 그러나 동일한 리소스 어댑터를 사용하여 JBoss EAP의 원격 인스턴스 내에서 실행되는 Artemis 서버에 연결할 수 있습니다.

중요

messaging-activemq 하위 시스템에서 기본적으로 구성된 The activemq- ra 풀링 연결 팩토리에는 java:jboss/DefaultJMSConnectionFactory 항목이 할당되어 있습니다. 이 항목은 messaging-activemq 하위 시스템에서 필요합니다. the activemq-ra 풀링된 연결 팩토리를 제거하기로 결정한 경우 이 항목을 다른 연결 팩토리에 할당해야 합니다. 그렇지 않으면 배포 시 서버 로그에 다음 오류가 표시됩니다. 

WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"]
Copy to Clipboard Toggle word wrap

JBoss EAP의 원격 인스턴스 내에서 실행되는 Artemis 서버에 연결하려면 아래 단계에 따라 새 pooled-connection-factory 를 생성합니다.

  1. 원격 메시징 서버를 가리키는 아웃바운드-소켓-바인딩을 생성합니다. 

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-server:add(host=<server host>, port=8080)
    Copy to Clipboard Toggle word wrap

  2. 1단계에서 생성된 아웃바운드-소켓-바인딩을 참조하는 원격 연결기를 만듭니다. 

    /subsystem=messaging-activemq/server=default/http-connector=remote-http-connector:add(socket-binding=remote-server,endpoint=http-acceptor)
    Copy to Clipboard Toggle word wrap

  3. 2단계에서 생성된 원격 연결을 참조하는 pooled-connection-factory를 생성합니다. 

    /subsystem=messaging-activemq/server=default/pooled-connection-factory=remote-artemis:add(connectors=[remote-http-connector], entries=[java:/jms/remoteCF])
    Copy to Clipboard Toggle word wrap
    참고

    Artemis 1.x는 대상 이름에 접두사가 필요함(주제의 경우 jms.topic, 대기열의 경우 jms.queue). Artemis 2.x는 접두사가 필요하지 않지만 Artemis 1.x와의 호환성을 위해 EAP는 접두사를 계속 추가하고 호환성 모드에서 실행되도록 Artemis를 지시합니다. 원격 Artemis 2.x 서버에 연결하는 경우 호환성 모드가 아니므로 접두사가 필요하지 않을 수 있습니다. 접두사 없이 대상을 사용할 때는 enable-amq1-prefix 속성을 false 로 설정하여 접두사를 포함하지 않도록 연결 팩토리를 구성할 수 있습니다.

pooled-connection-factory를 사용하도록 MDB 구성

pooled-connection-factory 가 원격 Artemis 서버에 연결하도록 구성된 후 원격 서버에서 메시지를 읽고자 하는 Message-Driven Beans(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) {
       ...
    }
}
Copy to Clipboard Toggle word wrap

MDB에서 원격 서버에 메시지를 보내야 하는 경우 JNDI 항목 중 하나를 사용하여 조회하여 pooled-connection-factory 를 삽입해야 합니다. 

@Inject
@JMSConnectionFactory("java:/jms/remoteCF")
private JMSContext context;
Copy to Clipboard Toggle word wrap
자카르타 메시징 대상 구성

또한 MDB는 메시지를 사용할 대상을 지정해야 합니다. 이 작업을 수행하는 표준 방법은 로컬 서버의 JNDI 조회에 해당하는 destinationLookup 활성화 구성 속성을 정의하는 것입니다. 

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

로컬 서버에 원격 Artemis 서버에 대한 JNDI 바인딩이 포함되지 않은 경우 대상 활성화 구성 속성을 사용하여 원격 Artemis 서버에 구성된 대로 대상 이름을 지정하고 useJNDI 활성화 구성 속성을 false로 설정합니다. 이는 JNDI 조회 없이도 Jakarta Messaging 대상을 자동으로 생성하도록 Artemis 리소스 어댑터에 지시합니다. 

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

위의 예에서 활성화 구성 속성은 원격 Artemis 서버에서 호스팅되는 myQueue 라는 Jakarta Messaging Queue의 메시지를 사용하도록 MDB를 구성합니다. 대부분의 경우 MDB는 사용된 메시지를 처리하기 위해 다른 대상을 조회할 필요가 없으며 메시지에 정의된 경우 JMSReplyTo 대상을 사용할 수 있습니다.

MDB에 원격 서버에 정의된 다른 Jakarta Messaging 대상이 필요한 경우 클라이언트 측 JNDI를 사용해야 합니다. 자세한 내용은 서버에 연결을 참조하십시오.

31.3. Red Hat AMQ에 연결하도록 Artemis 리소스 어댑터 구성
링크 복사

Red Hat AMQ 7의 원격 설치에 연결하도록 통합된 Artemis 리소스 어댑터를 구성할 수 있습니다. 그러면 JBoss EAP 7.4 애플리케이션의 자카르타 메시징 공급자가 됩니다. 이를 통해 JBoss EAP는 원격 Red Hat AMQ 7 서버의 클라이언트가 될 수 있습니다.

AMQP 또는 STOMP와 같은 다른 메시징 프로토콜에 대한 지원이 필요한 경우 Red Hat AMQ 7을 메시징 브로커로 구성해야 합니다. 그런 다음 JBoss EAP 서버에 통합된 Artemis 리소스 어댑터를 사용하여 배포된 애플리케이션의 메시지를 처리할 수 있습니다.

통합 리소스 어댑터의 제한 사항
큐 및 주제의 동적 생성

JBoss EAP 7.4에 통합된 Artemis 리소스 어댑터는 Red Hat AMQ 7 브로커에서 대기열과 토픽의 동적 생성을 지원하지 않습니다. 원격 Red Hat AMQ 7 서버에서 모든 대기열 및 주제 대상을 직접 구성해야 합니다.

연결 팩트 생성

Red Hat AMQ를 사용하면 pooled-connection-factory와 external- context 를 모두 사용하여 연결 팩토리를 구성할 수 있지만 각 연결 팩토리가 생성되는 방식에서 차이가 있습니다. external-context 를 사용하여 연결 팩토리를 만들 때 Jakarta Messaging 사양에 정의된 대로 간단한 Jakarta Messaging 연결 팩토리를 생성합니다. 새로 생성된 연결 팩토리는 기본적으로 messaging-activemq 하위 시스템에서 정의되는 RemoteConnectionFactory 와 동일합니다. 이 연결 팩토리는 애플리케이션 서버의 다른 구성 요소와 독립적입니다. 즉, 트랜잭션 관리자나 보안 관리자와 같은 다른 구성 요소와도 사용할 수 없습니다. 이러한 이유로 pooled-connection-factory 만 JBoss EAP 7에서 연결 팩토리를 만드는 데 사용할 수 있습니다. external-context 는 원격 AMQ 7 브로커에 이미 구성된 Jakarta Messaging 대상을 JBoss EAP 7 서버의 JNDI 트리에 등록하는 데만 사용할 수 있으므로 로컬 배포에서 조회하거나 주입할 수 있습니다.

external-context 또는 connection- factory 요소를 구성하여 만든 연결 팩토리는 Artemis 리소스 어댑터를 사용하지 않으므로 원격 AMQ 7 브로커에 연결하는 데 사용할 수 없습니다. pooled-connection-factory 요소를 구성하여 생성된 연결 팩토리만 원격 AMQ7 브로커에 연결할 때 지원됩니다.

원격 Red Hat AMQ Server를 사용하도록 JBoss EAP 구성

관리 CLI를 사용하여 다음 단계에 따라 Red Hat AMQ 7의 원격 설치를 메시징 공급자로 사용하도록 JBoss EAP를 구성할 수 있습니다.

  1. Red Hat AMQ 7 broker.xml 배포 설명자 파일에서 큐를 구성합니다. 

    <configuration xmlns="urn:activemq"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">

    <core xmlns="urn:activemq:core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:activemq:core ">
        ...
        <acceptors>
            <acceptor name="netty-acceptor">tcp://localhost:61616?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.
            </acceptor>
        </acceptors>
        <addresses>
            <address name="MyQueue">
                <anycast>
                    <queue name="MyQueue" />
                </anycast>
            </address>
            <address name="MyOtherQueue">
                <anycast>
                    <queue name="MyOtherQueue" />
                </anycast>
            </address>
            <address name="MyTopic">
                <multicast/>
            </address>
        <addresses>
        ...
    </core>
</configuration>
    Copy to Clipboard Toggle word wrap
    참고

    JBoss EAP에 포함된 Artemis 리소스 어댑터는 ActiveMQ Artemis Jakarta Messaging Client 2.x를 사용합니다. 이 클라이언트에는 주소에 anycastPrefix 및 multicastPrefix 접두사가 필요합니다. 또한 큐 이름이 주소 이름과 같을 것으로 예상됩니다.

  2. 원격 커넥터를 만듭니다. 

    /subsystem=messaging-activemq/remote-connector=netty-remote-throughput:add(socket-binding=messaging-remote-throughput)
    Copy to Clipboard Toggle word wrap

    그러면 messaging -activemq 하위 시스템에서 다음과 같은 remote- connector 가 생성됩니다. 

    <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
    ...
    <remote-connector name="netty-remote-throughput" socket-binding="messaging-remote-throughput"/>
    ...
</subsystem>
    Copy to Clipboard Toggle word wrap

  3. 원격 대상 아웃바운드 소켓 바인딩을 추가합니다. 

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=messaging-remote-throughput:add(host=localhost, port=61616)
    Copy to Clipboard Toggle word wrap

    이렇게 하면 outbound- socket -binding 요소 구성에 다음과 같은 remote- destination 이 생성됩니다. 

    <outbound-socket-binding name="messaging-remote-throughput">
    <remote-destination host="localhost" port="61616"/>
</outbound-socket-binding>
    Copy to Clipboard Toggle word wrap

  4. 원격 커넥터에 대해 풀링된 연결 팩토리를 추가합니다. 

    /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra-remote:add(transaction=xa,entries=[java:/RemoteJmsXA, java:jboss/RemoteJmsXA],connectors=[netty-remote-throughput])
    Copy to Clipboard Toggle word wrap

    그러면 messaging -activemq 하위 시스템에 다음과 같은 pooled-connection- factory 가 생성됩니다. 

    <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
    ...
    <pooled-connection-factory name="activemq-ra-remote" entries="java:/RemoteJmsXA java:jboss/RemoteJmsXA" connectors="netty-remote-throughput"/>
    ...
</subsystem>
    Copy to Clipboard Toggle word wrap
    참고

    Artemis 1.x는 대상 이름에 접두사가 필요함(주제의 경우 jms.topic, 대기열의 경우 jms.queue). Artemis 2.x는 접두사가 필요하지 않지만 Artemis 1.x와의 호환성을 위해 EAP는 접두사를 계속 추가하고 호환성 모드에서 실행되도록 Artemis를 지시합니다. 원격 Artemis 2.x 서버에 연결하는 경우 호환성 모드가 아니므로 접두사가 필요하지 않을 수 있습니다. 접두사 없이 대상을 사용할 때는 enable-amq1-prefix 속성을 false 로 설정하여 접두사를 포함하지 않도록 연결 팩토리를 구성할 수 있습니다.

  5. 큐 및 토픽에 대한 external-context 바인딩을 만듭니다. 

    /subsystem=naming/binding=java\:global\/remoteContext:add(binding-type=external-context, class=javax.naming.InitialContext, module=org.apache.activemq.artemis, environment=[java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory, java.naming.provider.url=tcp://127.0.0.1:61616, queue.MyQueue=MyQueue, queue.MyOtherQueue=MyOtherQueue, topic.MyTopic=MyTopic])
    Copy to Clipboard Toggle word wrap

    이렇게 하면 네이밍 하위 시스템에서 다음과 같은 external-context 바인딩이 생성됩니다. 

    <subsystem xmlns="urn:jboss:domain:naming:2.0">
    ...
    <bindings>
        <external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
            <environment>
                <property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
                <property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
                <property name="queue.MyQueue" value="MyQueue"/>
                <property name="queue.MyOtherQueue" value="MyOtherQueue"/>
                <property name="topic.MyTopic" value="MyTopic"/>
            </environment>
        </external-context>
    </bindings>
    ...
</subsystem>
    Copy to Clipboard Toggle word wrap

  6. JNDI 이름을 Red Hat AMQ 7 주소 이름 값으로 설정하여 Jakarta Messaging 대기열 및 토픽에 대한 조회 항목을 생성합니다. 이렇게 하면 JNDI 이름과 Red Hat AMQ 7 주소 이름 사이에 매핑이 생성됩니다. 

    /subsystem=naming/binding=java\:\/MyQueue:add(lookup=java:global/remoteContext/MyQueue,binding-type=lookup)
/subsystem=naming/binding=java\:\/MyOtherQueue:add(lookup=java:global/remoteContext/MyOtherQueue,binding-type=lookup)
/subsystem=naming/binding=java\:\/MyTopic:add(lookup=java:global/remoteContext/MyTopic,binding-type=lookup)
    Copy to Clipboard Toggle word wrap

    이렇게 하면 네이밍 하위 시스템에서 다음 조회 구성이 생성됩니다. 

    <subsystem xmlns="urn:jboss:domain:naming:2.0">
    ...
    <lookup name="java:/MyQueue" lookup="java:global/remoteContext/MyQueue"/>
    <lookup name="java:/MyOtherQueue" lookup="java:global/remoteContext/MyOtherQueue"/>
    <lookup name="java:/MyTopic" lookup="java:global/remoteContext/MyTopic"/>
    ...
</subsystem>
    Copy to Clipboard Toggle word wrap

    또는 명명 하위 시스템을 구성하는 대신 /subsystem=messaging-activemq/external-jms-queue 또는 /subsystem=messaging-activemq/external-jms-topic 리소스를 정의합니다. 예를 들면 다음과 같습니다. 

    /subsystem=messaging-activemq/external-jms-queue=MyQueue:add(entries=[java:/MyQueue])
    Copy to Clipboard Toggle word wrap

    이렇게 하면 다음 리소스가 생성됩니다. 

    <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
    ...
    <external-jms-queue name="MyQueue" entries="java:/MyQueue"/>
    ...
</subsystem>
    Copy to Clipboard Toggle word wrap
    참고

    external-jms-queue 리소스는 대기열 관리 및 통계를 위한 작업을 제공하지 않습니다.

이제 Red Hat AMQ 7의 원격 설치를 메시징 프로바이더로 사용하도록 JBoss EAP가 구성되어 있습니다.

31.4. 원격 Artemis 기반 브로커에 대한 자카르타 메시징 리소스 구성
링크 복사

관리 CLI에서 @JMSConnectionFactoryDefinition 주석 또는 @JMSDestinationDefinition 주석을 사용하여 Red Hat AMQ 7과 같은 원격 Artemis 기반 브로커의 Jakarta Messaging 리소스를 구성할 수 있습니다. 관리 콘솔에서 리소스를 구성할 수도 있습니다.

원격 ActiveMQ 서버 리소스에는 Artemis의 로컬 인스턴스가 필요하지 않습니다. 이를 통해 JBoss EAP 이미지의 메모리 및 CPU 공간을 줄일 수 있습니다.

JBoss EAP는 @JMSConnectionFactoryDefinition 주석을 사용하여 연결 팩토리를 정의합니다. 이 연결 팩토리는 로컬 또는 원격 Artemis 브로커에 연결할 수 있습니다. 그런 다음 @JMSConnectionFactoryDefinition 주석의 resourceAdapter 요소는 원격 Artemis 브로커에 연결할 수 있는 messaging -subsystem에 정의된 pooled- connection-factory 의 이름을 나타냅니다. resourceAdapter 요소는 연결 팩토리를 만드는 데 사용되는 리소스 어댑터 또는 연결 팩토리가 정의된 리소스 어댑터를 정의합니다.

resourceAdapter 요소가 @JMSConnectionFactoryDefinition 주석에 정의되지 않은 경우 messaging-activemq 하위 시스템은 기본적으로 연결 팩토리의 JNDI 이름을 사용합니다. 이를 기본 바인딩이라고 합니다. 기본 바인딩은 /subsystem=ee/service=default -bindings에서 jms-connection- factory 특성을 사용하여 정의됩니다. resourceAdapter 요소를 지정하거나 jms-connection-factory 의 기본 바인딩에서 정의할 수 있으며 원격 브로커에 대한 pooled-connection-factory 인 경우 이를 사용하여 원격 브로커에 연결할 수 있습니다.

messaging-activemq 하위 시스템에 resourceAdapter 가 정의되지 않거나 jms- connection-factory 의 기본 바인딩에서 가져올 수 없는 경우 Jakarta Messaging 리소스를 생성하는 작업은 리소스 어댑터의 admin-objects 및 connection-definitions 리소스를 기반으로 resource- adapter s 하위 시스템에 위임됩니다.

다음 섹션에서는 @JMSConnectionFactoryDefinition 주석을 구성하고 사용하는 방법에 대한 예를 제공합니다.

기본 리소스 어댑터를 사용하여 @JMSConnectionFactoryDefinition 구성

  1. 원격 인스턴스에 대한 소켓 바인딩을 생성합니다. 

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=messaging-remote-throughput:add(host=127.0.0.2, port=5445)
    Copy to Clipboard Toggle word wrap

  2. 커넥터를 생성합니다. 

    /subsystem=messaging-activemq/remote-connector=remote-amq:add(socket-binding="messaging-remote-throughput")
    Copy to Clipboard Toggle word wrap

  3. 풀링된 연결 팩토리를 생성합니다. 

    /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra-remote:add(entries=["java:/jms/remote-amq/JmsConnectionFactory"],connectors=["remote-amq"]
    Copy to Clipboard Toggle word wrap

  4. ee 하위 시스템에 대한 기본 Jakarta Messaging 연결 팩토리를 정의합니다. 

    /subsystem=ee/service=default-bindings:write-attribute(name=jms-connection-factory, value="java:/jms/remote-amq/JmsConnectionFactory")
    Copy to Clipboard Toggle word wrap

  5. 애플리케이션 코드에서 @JMSConnectionFactoryDefinition 주석을 사용합니다. 

    @JMSConnectionFactoryDefinition(name="java:/jms/remote-amq/JmsConnectionFactory")
    Copy to Clipboard Toggle word wrap
원격 Artemis Broker를 사용하여 @JMSConnectionFactoryDefinition 구성

  1. 커넥터를 생성합니다. 

    /subsystem=messaging-activemq/remote-connector=remote-amq:add(socket-binding="messaging-remote-throughput")
    Copy to Clipboard Toggle word wrap

  2. 풀링된 연결 팩토리를 생성합니다. 

    /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra-remote:add(entries=["java:/jms/remote-amq/JmsConnectionFactory"],connectors=["remote-amq"])
    Copy to Clipboard Toggle word wrap

  3. ee 하위 시스템에 대한 기본 Jakarta Messaging 연결 팩토리를 정의합니다. 

    /subsystem=ee/service=default-bindings:write-attribute(name=jms-connection-factory, value="java:/jms/remote-amq/JmsConnectionFactory")
    Copy to Clipboard Toggle word wrap

  4. 애플리케이션 코드에서 @JMSConnectionFactoryDefinition 주석을 사용합니다. 

    @JMSConnectionFactoryDefinition(
        name="java:app/myCF"
        resourceAdapter="myPCF"
)
    Copy to Clipboard Toggle word wrap
타사 JMS 리소스 어댑터를 사용하여 @JMSConnectionFactoryDefinition 구성

  1. 커넥터를 생성합니다. 

    /subsystem=messaging-activemq/remote-connector=remote-amq:add(socket-binding="messaging-remote-throughput")
    Copy to Clipboard Toggle word wrap

  2. 풀링된 연결 팩토리를 생성합니다. 

    /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra-remote:add(entries=["java:/jms/remote-amq/JmsConnectionFactory"],connectors=["remote-amq"])
    Copy to Clipboard Toggle word wrap

  3. ee 하위 시스템에 대한 기본 Jakarta Messaging 연결 팩토리를 정의합니다. 

    /subsystem=ee/service=default-bindings:write-attribute(name=jms-connection-factory, value="java:/jms/remote-amq/JmsConnectionFactory")
    Copy to Clipboard Toggle word wrap

  4. 애플리케이션 코드에서 @JMSConnectionFactoryDefinition 주석을 사용합니다. 

    @JMSConnectionFactoryDefinition(
        name="java:app/myCF"
        resourceAdapter="wsmq"
)
    Copy to Clipboard Toggle word wrap

서버 리소스를 사용하여 로컬 브로커에 pooled-connection-factory 에 필요한 대상을 생성할 수 있습니다.

resourceAdapter 요소가 pooled-connection-factory 이름을 가리키고 로컬 브로커(예: /subsystem/messaging-activemq/server=default )에 정의된 경우 로컬 Artemis 브로커에 대상을 생성합니다.

참고

원격 Artemis-based 브로커에서 대상을 생성해야 하는 경우 pooled-connection-factory 는 messaging-activemq 하위 시스템에 정의해야 합니다.

@JMSDestinationDefinition 주석에 설정된 resourceAdapter 요소가 messaging-activemq 하위 시스템에서 서버에 대해 정의된 resourceAdapter 요소와 일치하는 경우, pooled- connection-factory 의 커넥터가 로컬 또는 원격 Artemis 브로커를 가리키는지 여부에 관계없이 이 브로커에 대상이 생성됩니다.

JMSDestinationDefinition 주석을 사용하여 자카르타 메시징 리소스 구성

  1. 커넥터를 생성합니다. 

    /subsystem=messaging-activemq/remote-connector=remote-amq:add(socket-binding="messaging-remote-throughput")
    Copy to Clipboard Toggle word wrap

  2. 풀링된 연결 팩토리를 생성합니다. 

    /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra-remote:add(entries=["java:/jms/remote-amq/JmsConnectionFactory"],connectors=["remote-amq"])
    Copy to Clipboard Toggle word wrap

  3. ee 하위 시스템에 대한 기본 Jakarta Messaging 연결 팩토리를 정의합니다. 

    /subsystem=ee/service=default-bindings:write-attribute(name=jms-connection-factory, value="java:/jms/remote-amq/JmsConnectionFactory")
    Copy to Clipboard Toggle word wrap

  4. 애플리케이션 코드에서 @JMSDestinationDefinition 주석을 사용합니다. 

    @JMSDestinationDefinition(
    name = "java:/jms/queue/MessageBeanQueue",
    interfaceName = "javax.jms.Queue",
    destinationName = "MessageBeanQueue"
    properties= {
        "management-address=remote-activemq.management"
    }
)
    Copy to Clipboard Toggle word wrap

31.4.3. 관리 콘솔을 사용하여 원격 ActiveMQ 서버 리소스 구성
링크 복사

관리 콘솔에서 다음 원격 ActiveMQ 서버 리소스를 구성할 수 있습니다.

  • 일반 커넥터
  • VM 커넥터
  • HTTP 커넥터
  • 원격 커넥터
  • 검색 그룹
  • 연결 팩토리
  • 풀링된 연결 팩토리
  • 외부 JMS 대기열
  • 외부 JMS 주제

관리 콘솔에서 원격 ActiveMQ 서버 리소스를 구성하려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스하여 Configuration → Subsystems → Messaging (ActiveMQ) → Remote ActiveMQ Server 로 이동하여 보기를 클릭합니다.
  2. 네비게이션 창에서 구성할 리소스를 클릭합니다.

31.5. Red Hat JBoss A-MQ 리소스 어댑터 배포
링크 복사

Red Hat JBoss A-MQ 제품에서 제공하는 리소스 어댑터를 배포하고 Red Hat JBoss A-MQ 6.3.0과 같이 JBoss EAP의 외부 자카르타 메시징 공급자가 될 수 있습니다.

Red Hat JBoss A-MQ 리소스 어댑터를 배포하고 구성하는 방법에 대한 자세한 내용은 Red Hat JBoss A-MQ 설명서 모음에 있는 JBoss Enterprise Application Platform과 통합 에서 ActiveMQ 리소스 어댑터 설치를 참조하십시오.

참고

제품 이름이 6.x 릴리스의 Red Hat JBoss A-MQ에서 7.x 릴리스의 Red Hat AMQ로 변경되었습니다.

31.5.1. Red Hat JBoss A-MQ 6 리소스 어댑터 문제
링크 복사

  • JBoss EAP는 종속되지 않은 리소스를 찾아 애플리케이션을 추적 및 모니터링합니다. 대부분의 경우 유용하지만 애플리케이션에서 단일 메서드에서 닫힌 UserTransaction 인스턴스를 다시 사용하려고 할 때 이러한 모니터링으로 예기치 않은 동작이 발생할 수 있습니다. 애플리케이션이 이러한 방식으로 연결을 재사용하는 경우 Red Hat JBoss A -MQ 리소스 어댑터를 구성할 때 <connection-definition/> 요소에 tracking="false" 속성을 추가합니다. 

    <connection-definition class-name="..." tracking="false" ... />
    Copy to Clipboard Toggle word wrap
  • Red Hat JBoss A-MQ 6 리소스 어댑터는 JBoss EAP에서 사용하는 Narayana API에서 XAResourceWrapper 를 구현하지 않습니다. 결과적으로 트랜잭션 관리자가 모든 XA 트랜잭션 참가자에게 커밋을 보낸 다음 응답을 기다리는 동안 충돌하는 경우, 커밋된 트랜잭션의 레코드가 해당 오브젝트 저장소에서 제거될 때까지 무기한 경고를 기록합니다.

  • Red Hat JBoss A-MQ 6 리소스 어댑터는 네트워크 연결 해제와 같은 오류가 발생하면 커밋 메서드 프로토콜을 호출하는 동안 발생하는 코드 XAER_RMERR 을 반환합니다. 이 동작은 올바른 반환 코드가 XA ER_RMFAIL 또는 XA ER_ RETRY여야 하므로 XA 사양이 중단됩니다. 결과적으로 트랜잭션이 메시지 브로커 측에서 알 수 없는 상태로 유지되므로 경우에 따라 데이터 불일치가 발생할 수 있습니다. 예기치 않은 오류 코드가 반환되면 아래 메시지와 비슷한 메시지가 기록됩니다. 

    WARN [com.arjuna.ats.jtax] ...: XAResourceRecord.rollback caused an XA error: ARJUNA016099: Unknown error code:0 from resource ... in transaction ...: javax.transaction.xa.XAException: Transaction ... has not been started.
    Copy to Clipboard Toggle word wrap
  • Red Hat JBoss A-MQ 6.x는 Java EE 6에 포함된 JMS 1.1 사양을 지원합니다. Jakarta EE 8에서 도입되었으며 JBoss EAP 7에서 지원되는 Jakarta Messaging 2.0 사양을 지원하지 않습니다. 원격 Red Hat JBoss A-MQ 브로커에 메시지를 보내려면 애플리케이션 코드 내에서 JMS 1.1 API 를 사용해야 합니다. Red Hat JBoss A-MQ 6.x 지원 표준에 대한 자세한 내용은 Red Hat JBoss A-MQ 지원 표준 및 프로토콜을 참조하십시오.

31.6. IBM MQ 리소스 어댑터 배포
링크 복사

IBM MQ 정보

IBM MQ는 분산 시스템의 애플리케이션이 서로 통신할 수 있도록 하는 IBM의 MOM(Messaging Oriented Middleware) 제품입니다. 이 작업은 메시지 및 메시지 큐를 사용하여 수행됩니다. IBM MQ는 메시지 큐에 메시지를 전달하고 메시지 채널을 사용하여 다른 대기열 관리자에게 데이터를 전송하는 일을 담당합니다. IBM MQ에 대한 자세한 내용은 IBM 제품 웹 사이트의 IBM MQ 를 참조하십시오.

요약

IBM MQ는 JBoss EAP 7.4의 외부 자카르타 메시징 공급자로 구성할 수 있습니다. 이 섹션에서는 JBoss EAP에서 IBM MQ 리소스 어댑터를 배포하고 구성하는 단계를 다룹니다. 이 배포 및 구성은 관리 CLI 도구 또는 웹 기반 관리 콘솔을 사용하여 수행할 수 있습니다. IBM MQ의 지원되는 구성에 대한 최신 정보는 JBoss EAP 지원 구성을 참조하십시오.

참고

구성 변경 사항을 적용하려면 IBM MQ 리소스 어댑터를 구성한 후 시스템을 다시 시작해야 합니다.

사전 요구 사항

시작하기 전에 IBM MQ 리소스 어댑터 버전을 확인하고 구성 속성을 이해해야 합니다.

  • IBM MQ 리소스 어댑터는 wmq.jmsra.rar 라는 RR(리소스 아카이브) 파일로 제공됩니다. /opt/ mqm/java/lib/jca/wmq.jmsra.rar에서 w mq.jmsra.rar 파일을 가져올 수 있습니다. JBoss EAP의 각 릴리스에서 지원되는 특정 버전에 대한 정보는 JBoss EAP 지원 구성을 참조하십시오.

  • 다음 IBM MQ 구성 값을 알아야 합니다. 이러한 값에 대한 자세한 내용은 IBM MQ 제품 설명서를 참조하십시오.

    • MQ_QUEUE_MANAGER: IBM MQ 큐 관리자의 이름
    • MQ_HOST_NAME: IBM MQ 큐 관리자 연결에 사용되는 호스트 이름
    • MQ_CHANNEL_NAME: IBM MQ 큐 관리자에 연결하는 데 사용되는 서버 채널
    • MQ_QUEUE_NAME: 대상 큐의 이름
    • MQ_TOPIC_NAME: 대상 주제의 이름
    • MQ_PORT: IBM MQ 큐 관리자에 연결하는 데 사용되는 포트
    • MQ_CLIENT: 전송 유형

  • 아웃바운드 연결의 경우 다음 구성 값에 익숙해야 합니다.

    • MQ_CONNECTIONFACTORY_NAME: 원격 시스템에 대한 연결을 제공할 연결 팩토리 인스턴스의 이름
절차
참고

다음은 IBM에서 제공하는 기본 구성이며 변경될 수 있습니다. 자세한 내용은 IBM MQ 설명서를 참조하십시오.

  1. 먼저 wmq.jmsra.rar 파일을 EAP_HOME/standalone/deployments/ 디렉터리에 복사하여 리소스 어댑터를 수동으로 배포합니다.

  2. 그런 다음 관리 CLI를 사용하여 리소스 어댑터를 추가하고 구성합니다. 

    /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar:add(archive=wmq.jmsra.rar, transaction-support=XATransaction)
    Copy to Clipboard Toggle word wrap

    트랜잭션 지원 요소가 XATransaction 으로 설정되었는지 확인합니다. 트랜잭션을 사용할 때는 아래 예제와 같이 XA 복구 데이터 소스의 보안 도메인을 제공해야 합니다. 

    /subsystem=resource-adapters/resource-adapter=test/connection-definitions=test:write-attribute(name=recovery-security-domain,value=myDomain)
    Copy to Clipboard Toggle word wrap

    XA 복구에 대한 자세한 내용은 JBoss EAP 구성 가이드에서 XA 복구 구성을 참조하십시오.

    트랜잭션이 아닌 배포의 경우 트랜잭션 지원 값을 NoTransaction 으로 변경합니다. 

    /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar:add(archive=wmq.jmsra.rar, transaction-support=NoTransaction)
    Copy to Clipboard Toggle word wrap

  3. 이제 리소스 어댑터가 생성되었으므로 필요한 구성 요소를 추가할 수 있습니다.

    1. 큐에 대한 admin-object 를 추가하고 해당 속성을 구성합니다. 

      /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=queue-ao:add(class-name=com.ibm.mq.connector.outbound.MQQueueProxy, jndi-name=java:jboss/MQ_QUEUE_NAME)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=queue-ao/config-properties=baseQueueName:add(value=MQ_QUEUE_NAME)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=queue-ao/config-properties=baseQueueManagerName:add(value=MQ_QUEUE_MANAGER)
      Copy to Clipboard Toggle word wrap

    2. 주제의 admin-object 를 추가하고 해당 속성을 구성합니다. 

      /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=topic-ao:add(class-name=com.ibm.mq.connector.outbound.MQTopicProxy, jndi-name=java:jboss/MQ_TOPIC_NAME)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=topic-ao/config-properties=baseTopicName:add(value=MQ_TOPIC_NAME)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=topic-ao/config-properties=brokerPubQueueManager:add(value=MQ_QUEUE_MANAGER)
      Copy to Clipboard Toggle word wrap

    3. 관리되는 연결 팩토리에 대한 연결 정의를 추가하고 해당 속성을 구성합니다. 

      /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=mq-cd:add(class-name=com.ibm.mq.connector.outbound.ManagedConnectionFactoryImpl, jndi-name=java:jboss/MQ_CONNECTIONFACTORY_NAME, tracking=false)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=mq-cd/config-properties=hostName:add(value=MQ_HOST_NAME)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=mq-cd/config-properties=port:add(value=MQ_PORT)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=mq-cd/config-properties=channel:add(value=MQ_CHANNEL_NAME)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=mq-cd/config-properties=transportType:add(value=MQ_CLIENT)

/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=mq-cd/config-properties=queueManager:add(value=MQ_QUEUE_MANAGER)
      Copy to Clipboard Toggle word wrap

  4. JBoss EAP의 EJB3 메시징 시스템의 기본 프로바이더를 JBoss EAP 7 메시징에서 IBM MQ로 변경하려면 관리 CLI를 사용하여 다음과 같이 ejb3 하위 시스템을 수정합니다. 

    /subsystem=ejb3:write-attribute(name=default-resource-adapter-name,value=wmq.jmsra.rar)
    Copy to Clipboard Toggle word wrap

  5. 다음과 같이 MDB 코드에서 @ActivationConfigProperty 및 @ResourceAdapter 주석을 구성합니다. 

    @MessageDriven(name="IbmMqMdb", activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType",propertyValue = "javax.jms.Queue"),
    @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"),
    @ActivationConfigProperty(propertyName = "hostName", propertyValue = "MQ_HOST_NAME"),
    @ActivationConfigProperty(propertyName = "port", propertyValue = "MQ_PORT"),
    @ActivationConfigProperty(propertyName = "channel", propertyValue = "MQ_CHANNEL_NAME"),
    @ActivationConfigProperty(propertyName = "queueManager", propertyValue = "MQ_QUEUE_MANAGER"),
    @ActivationConfigProperty(propertyName = "destination", propertyValue = "MQ_QUEUE_NAME"),
    @ActivationConfigProperty(propertyName = "transportType", propertyValue = "MQ_CLIENT")
})

@ResourceAdapter(value = "wmq.jmsra-VERSION.rar")
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class IbmMqMdb implements MessageListener {
}
    Copy to Clipboard Toggle word wrap

    @ResourceAdapter 값의 VERSION 을 RAR 이름의 실제 버전으로 바꿉니다.

  6. 리소스 어댑터를 활성화합니다. 

    /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar:activate()
    Copy to Clipboard Toggle word wrap

31.6.1. IBM MQ 리소스 어댑터의 제한 사항 및 알려진 문제
링크 복사

다음 표에는 IBM MQ 리소스 어댑터의 알려진 문제가 나열되어 있습니다. 버전 열의 확인 표시(cd)는 해당 버전의 리소스 어댑터에 문제가 있음을 나타냅니다.

Expand
표 31.1. IBM MQ 리소스 어댑터의 알려진 문제
JIRA문제 설명IBM MQ 8IBM MQ 9

JBEAP-503

IBM MQ 리소스 어댑터는 Queue.toString() 및 QueueBrowser.getQueue().toString() 메서드에 대한 다양한 문자열 값을 반환합니다. 큐는 Queue Browser . htmlQueueBrowser.getQueue() 메서드에서 반환하는 com. ibm.mq.jms.MQQueue 클래스와 다른 com. ibm.mq.connector.outbound.MQQueue Proxy 클래스의 인스턴스입니다. 이러한 클래스에는 toString() 메서드의 다양한 구현이 포함되어 있습니다. 이러한 toString() 메서드를 사용하여 동일한 값을 반환할 수 없습니다.

✔

✔

JBEAP-511, JBEAP-550, JBEAP-3686

다음 제한 사항은 IBM MQ의 message 속성 이름에 적용됩니다.

  • 배포 설명자의 activation-config 섹션에서 _,& 또는 | 와 같은 특수 문자를 사용하여 destinationName 속성을 구성해서는 안 됩니다. 이러한 문자를 사용하면 com.ibm.msg.client.jms.DetailedInvalidDestinationException 예외와 함께 MDB 배포가 실패합니다.
  • 배포 설명자의 activation-config 섹션에서 java:/ 접두사를 사용하여 destinationName 속성을 구성할 수 없습니다. 이 접두사를 사용하면 MDB 배포가 com.ibm.msg.client.jms.DetailedInvalidDestinationException 예외와 함께 실패합니다.
  • 속성은 IBM MQ Jakarta Messaging 클래스에서 사용하도록 예약되므로 "JMS" 또는 "usr.JMS"로 시작해서는 안 됩니다. 예외는 IBM Knowledge Center 웹 사이트에 나와 있습니다.

각 버전의 리소스 어댑터에 대한 메시지 속성 이름 제한 전체 목록은 IBM MQ, 버전 8.0 및 IBM MQ의 속성 이름 제한사항, IBM 9.0 에 대한 속성 이름 제한 사항을 참조하십시오.

✔

✔

JBEAP-549

@ActivationConfigProperty 주석을 사용하여 MDB의 대상 속성 이름 값을 지정하는 경우 모든 대문자를 사용해야 합니다. 예를 들면 다음과 같습니다. 

@ActivationConfigProperty(propertyName = "destination", propertyValue = "QUEUE")
Copy to Clipboard Toggle word wrap

✔

✔

JBEAP-624

IBM MQ 리소스 어댑터를 사용하여 @JMSConnectionFactoryDefinition 주석을 사용하여 Jakarta EE 배포에 연결 팩토리를 생성하는 경우 resourceAdapter 속성을 지정해야 합니다. 그렇지 않으면 배포에 실패합니다. 

@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>"
    }
)
Copy to Clipboard Toggle word wrap

✔

✔

JBEAP-2339

IBM MQ 리소스 어댑터는 연결이 시작되기 전에 대기열과 주제에서 메시지를 읽을 수 있습니다. 즉, 소비자는 연결을 시작하기 전에 메시지를 사용할 수 있습니다. 이 문제를 방지하려면 원격 IBM MQ 브로커에서 만든 연결 팩토리를 사용하여 external-context 를 사용하고 IBM MQ 리소스 어댑터에서 만든 연결 팩토리를 사용하십시오.

✔

✔

JBEAP-3685

<transaction-support>XATransaction</transaction-support> 가 설정되면 주입을 사용하여 또는 수동으로 생성했는지에 관계없이 JMSContext.SESSION_TRANSACTED가 항상 JMSContext.SESSION_TRANSACTED 입니다.

다음 코드 예에서 @JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE) 가 무시되고 JMSContext는 JMSContext .SESSION_TRANSACTED 로 유지됩니다. 

@Inject
@JMSConnectionFactory("jms/CF")
@JMSPasswordCredential(userName="myusername", password="mypassword")
@JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE)
transient JMSContext context3;
Copy to Clipboard Toggle word wrap

✔

✔

JBEAP-14633

자카르타 메시징 사양에 따라 QueueSession 인터페이스를 사용하여 게시/서브스크립션 도메인과 관련된 개체를 생성할 수 없으며 세션에서 상속하는 특정 메서드에는 javax.jms.IllegalStateException 이 발생 해야 합니다. 이러한 메서드 중 하나는 QueueSession.createTemporaryTopic() 입니다. javax.jms.IllegalStateException 을 생성하는 대신 IBM MQ 리소스 어댑터에서 java.lang.NullPointerException 이 발생합니다.

✔

✔

JBEAP-14634

MQTopicProxy.getTopicName() 은 IBM MQ 브로커에서 설정한 것과 다른 주제 이름을 반환합니다. 예를 들어 주제 이름이 topic://MYTOPIC?XMSC_WMQ_BROKER_PUBQ_QMGR=QM 으로 설정된 경우 MQTopicProxy 는 topic://MYTOPIC 을 반환합니다.

✔

✔

JBEAP-14636

JMSContext 의 기본 자동 시작 설정은 false 입니다. 즉, 소비자가 생성될 때 JMSContext 에서 사용하는 기본 연결이 자동으로 시작되지 않습니다. 이 설정은 기본적으로 true 로 설정해야 합니다.

✔

✔

JBEAP-14640

잘못된 인증 정보가 사용되는 경우 IBM MQ 리소스 어댑터는 JMSSecurity Exception 대신 DetailedJMS Exception이 발생하고 서버 콘솔에 다음 오류를 기록합니다. 

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.
Copy to Clipboard Toggle word wrap

다음은 이 문제를 일으킬 수 있는 코드의 예입니다. 

QueueConnection qc = queueConnectionFactory.createQueueConnection("invalidUserName", "invalidPassword");
Copy to Clipboard Toggle word wrap

✔

✔

JBEAP-14642

MQMessageProducer.send(Destination destination, Message message) 및 MQMessageProducer.send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener) 메서드에서 리소스 어댑터로 구성된 잘못된 클래스의 변환으로 인해 IBM MQ 리소스 어댑터는 JMSException 을 발생시키고 서버 콘솔에 다음 오류 메시지를 기록합니다. 

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

이는 대기열 또는 토픽 조회에 사용되는 JNDI 이름이 com.ibm.mq.connector.outbound.MQQueueProxy/MQTopicProxy 이기 때문입니다.

✔

✔

JBEAP-14643

JMSProducer 인터페이스의 setDeliveryDelay(expDeliveryDelay) 메서드는 설정을 변경하지 않습니다. 이 메서드를 호출한 후에도 기본 설정 0 으로 남아 있습니다.

✔

✔

JBEAP-14670

UserTransaction.begin() 이전에 생성된 QueueSession 에서 작업이 수행되면 해당 작업은 트랜잭션의 일부로 간주되지 않습니다. 즉, 이 세션을 사용하여 큐로 전송된 모든 메시지는 UserTransaction.commit() 에 의해 커밋되지 않으며 UserTransaction.rollback() 이후에는 메시지가 대기열에 남아 있습니다.

✔

✔

JBEAP-14675

연결을 닫고 동일한 clientID 를 사용하여 JMSContext를 즉시 생성하는 경우 IBM MQ 리소스 어댑터는 서버 콘솔에 다음 오류를 간헐적으로 기록합니다. 

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.
Copy to Clipboard Toggle word wrap

이 문제는 동일한 clientID 와의 연결이 종료된 후 새 JMSContext 생성이 지연될 때 발생하지 않습니다.

✔

✔

JBEAP-15535

CMT(컨테이너 관리 트랜잭션)에서 상태 저장 세션 빈이 토픽으로 메시지를 보내려고 하면 전송된 메시지가 실패하고 다음 메시지가 표시됩니다. 

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

스택 추적은 다음과 같은 예외로 인해 발생하는 것으로 표시됩니다. 

com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2072' ('MQRC_SYNCPOINT_NOT_AVAILABLE')
Copy to Clipboard Toggle word wrap

✔

✔

JBEAP-20758

JBoss EAP에서 IBM MQ 8 또는 IBM MQ 9 리소스 어댑터 wmq.jmsra.rar 를 배포할 때 서버 콘솔에 다음 오류 메시지가 표시됩니다. 

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

IBM MQ v9.0.0.4 리소스 어댑터는 JBoss EAP 7.4에 대한 자카르타 메시징 공급자 테스트의 일부로 테스트되었습니다. 이 경고 메시지를 무시하도록 선택하거나 enabled 특성을 false 로 설정하여 아카이브 유효성 검사를 비활성화할 수 있습니다. 예를 들면 다음과 같습니다. 

/subsystem=jca/archive-validation=archive-validation:write-attribute(name=enabled, value=false)
Copy to Clipboard Toggle word wrap

✔

✔

31.7. 일반 자카르타 메시징 리소스 어댑터 배포
링크 복사

JBoss EAP는 타사 Jakarta Messaging 프로바이더와 작동하도록 구성할 수 있지만 모든 Jakarta Messaging 공급자가 자카르타 애플리케이션 플랫폼과의 통합을 위한 Jakarta Messaging Jakarta Connectors 리소스 어댑터를 생성하는 것은 아닙니다. 이 절차에서는 자카르타 메시징 공급자에 연결하기 위해 JBoss EAP에 포함된 일반 자카르타 메시징 리소스 어댑터를 구성하는 데 필요한 단계를 설명합니다. 이 절차에서 Tibco 8은 자카르타 메시징 공급자의 예로 사용됩니다. 다른 Jakarta Messaging 공급자는 다른 구성이 필요할 수 있습니다.

중요

일반 자카르타 메시징 리소스 어댑터를 사용하기 전에 Jakarta Messaging 공급자와 함께 JBoss EAP와 함께 사용할 수 있는 자체 리소스 어댑터가 있는지 확인합니다. 일반 Jakarta Messaging Jakarta Connectors 리소스 어댑터는 자카르타 메시징 공급자가 자체 리소스 어댑터를 제공하지 않는 경우에만 사용해야 합니다.

일반 리소스 어댑터를 구성하려면 다음을 수행해야 합니다.

  • Jakarta Messaging 공급자 서버가 이미 구성되어 있어야 하며 사용할 준비가 되어 있어야 합니다. 공급자의 Jakarta Messaging 구현에 필요한 모든 바이너리가 필요합니다.

  • 연결 팩토리, 큐 또는 토픽과 같은 자카르타 메시징 리소스를 조회할 수 있으려면 다음 Jakarta Messaging 공급자 속성의 값을 알아야 합니다.

    • java.naming.factory.initial
    • java.naming.provider.url
    • java.naming.factory.url.pkgs

이 절차에서 사용되는 예제 XML에서 이러한 매개 변수는 각각 PROVIDER_FACTORY_INITIAL,PROVIDER_ URL, PROVIDER_ CONNECTION_FACTORY 로 작성됩니다. 이러한 자리 표시자를 사용자 환경의 Jakarta Messaging 공급자 값으로 교체합니다.

  1. 리소스 어댑터 모듈을 생성하고 구성합니다.

    Jakarta Messaging 프로바이더와 연결하고 통신하는 데 필요한 모든 라이브러리를 포함하는 JBoss EAP 모듈을 생성합니다. 이 모듈의 이름은 org.jboss.genericjms.provider 로 지정됩니다.

    • 다음 디렉토리 구조를 생성합니다. EAP_HOME/modules/org/jboss/genericjms/provider/main

    • 공급자의 Jakarta Messaging 구현에 필요한 바이너리를 EAP_HOME/modules/org/jboss/genericjms/provider/main 에 복사합니다.

      참고

      Tibco의 경우 필요한 바이너리는 Tibco 설치의 lib 디렉토리의 tibjms.jar 및 tibcrypt.jar입니다.

    • EAP_HOME/modules/org/jboss/genericjms/provider/main 에서 module.xml 파일을 다음과 같이 생성하여 이전 단계의 JAR 파일을 리소스로 나열합니다. 

      <module xmlns="urn:jboss:module:1.5" name="org.jboss.genericjms.provider">
  <resources>
    <!-- all jars required by the Jakarta Messaging provider, in this case Tibco -->
    <resource-root path="tibjms.jar"/>
    <resource-root path="tibcrypt.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.jms.api"/>
  </dependencies>
</module>
      Copy to Clipboard Toggle word wrap

    • 다음 CLI 명령을 사용하여 모듈을 the ee 하위 시스템에 추가합니다. 

      /subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
      Copy to Clipboard Toggle word wrap

  2. 자카르타 메시징 공급자에 대한 Java 네이밍 및 디렉터리 인터페이스 외부 컨텍스트를 생성하고 구성합니다.

    연결 팩토리 및 대상과 같은 자카르타 메시징 리소스는 자카르타 메시징 공급자에서 조회됩니다. 이 리소스에 대한 모든 로컬 조회가 원격 자카르타 메시징 프로바이더에서 자동으로 리소스를 조회하도록 JBoss EAP 인스턴스에 외부 컨텍스트를 추가합니다.

    참고

    이 절차에서 EAP_HOME/standalone/configuration/standalone-full.xml 은 JBoss EAP 구성 파일로 사용됩니다.

    관리 CLI를 사용하여 외부 Java Naming 및 Directory Interface 컨텍스트를 생성하고 구성 속성을 포함합니다. 아래 예제의 속성은 원격 자카르타 메시징 공급자에 연결하려면 올바른 값으로 교체해야 합니다. 예를 들어 Tibco¢와 같은 일부 자카르타 메시징 프로바이더는 Java Naming 및 Directory Interface lookup(Name) 메서드를 지원하지 않습니다. 이 경우 이 문제를 해결하기 위해 true 값을 사용하여 org.jboss.as.naming.lookup.by.string 속성을 추가합니다. 필수 속성 및 해당 값에 대한 정보는 어댑터의 설명서를 확인하십시오. 

    /subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory,java.naming.provider.url=tcp://<hostname>:7222,org.jboss.as.naming.lookup.by.string=true])
    Copy to Clipboard Toggle word wrap

    외부 컨텍스트가 올바르게 구성된 경우 java:global/remoteJMS/ 로 시작하는 리소스에 대한 모든 Java Naming 및 Directory Interface 조회가 원격 자카르타 메시징 프로바이더에서 수행됩니다. 예를 들어 메시지 기반 빈이 java:global/remoteJMS/Queue1 에 대해 Java Naming 및 Directory Interface 조회를 수행하는 경우 외부 컨텍스트가 원격 자카르타 메시징 프로바이더에 연결하고 Queue1 리소스에 대한 조회를 수행합니다.

    또는 Java Naming 및 Directory Interface 이름을 찾을 때 external-context 를 사용하지 않고 Java Naming 및 Directory Interface를 원격 서버에 조회할 수 있습니다. 이렇게 하려면 CLI를 사용하여 아래 예제와 같이 external-context 를 참조하는 새 바인딩을 만듭니다. 

    /subsystem=naming/binding=java\:\/jms\/queue\/myQueue:add(binding-type=lookup, lookup=java:global/remoteJMS/jms/queue/myQueue)
    Copy to Clipboard Toggle word wrap

    위의 예에서 java:/jms/queue/myQueue 에 대한 Java 네이밍 및 디렉터리 인터페이스 조회를 수행하는 애플리케이션은 원격 서버에서 myQueue 라는 큐를 찾습니다.

  3. 일반 자카르타 메시징 리소스 어댑터를 생성합니다.

    관리 CLI를 사용하여 리소스 어댑터 생성 

    /subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
    Copy to Clipboard Toggle word wrap

  4. 일반 자카르타 메시징 리소스 어댑터를 구성합니다.

    관리 CLI를 사용하여 리소스 어댑터의 connection-definition 및 기타 요소를 구성합니다. 

    /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=tibco-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/XAQCF)

/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=tibco-cd/config-properties=ConnectionFactory:add(value=XAQCF)

/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=tibco-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.provider.url=tcp://<hostname>:7222")

/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=tibco-cd:write-attribute(name=security-application,value=true)
    Copy to Clipboard Toggle word wrap

  5. 일반 리소스 어댑터를 사용하도록 ejb3 하위 시스템에서 기본 메시지 기반 빈 풀을 구성합니다. 

    /subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
    Copy to Clipboard Toggle word wrap

이제 일반 자카르타 메시징 리소스 어댑터가 구성되어 사용할 준비가 되었습니다. 다음은 새 메시지 기반 빈을 만들 때 리소스 어댑터를 사용하는 예입니다.

예제: 일반 리소스 어댑터를 사용한 코드

@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.
  }
}
Copy to Clipboard Toggle word wrap

중요

일반 자카르타 메시징 리소스 어댑터를 사용하는 경우 잠재적인 NullPointerException 오류를 방지하려면 세션이 트랜잭션되도록 설정해야 합니다. 이 오류는 자카르타 EE 사양에 처리되지 않을 것임을 명시할 때 일반 Jakarta Messaging 리소스 어댑터가 매개 변수 처리를 시도하기 때문에 발생합니다. 이는 connection.createSession(true, Session.SESSION_TRANSACTED)을 수행하여 수행합니다.

리소스 어댑터에서 풀링된 연결 팩토리를 사용할 수도 있습니다. 

@Resource(lookup = "java:/jms/XAQCF")
private ConnectionFactory cf;
Copy to Clipboard Toggle word wrap

외부 컨텍스트의 리소스를 직접 주입할 수는 없지만 외부 컨텍스트를 주입한 다음 조회를 수행할 수 있습니다. 예를 들어 Tibco¢ 브로커에 배포된 큐에 대한 조회는 다음과 같습니다. 

@Resource(lookup = "java:global/remoteJMS")
private Context context;
...
Queue queue = (Queue) context.lookup("Queue1")
Copy to Clipboard Toggle word wrap

31.8. 리소스 주석 사용
링크 복사

@Resource 주석을 사용하여 Jakarta Enterprise Beans는 Jakarta Messaging 리소스 또는 연결 팩토리를 직접 주입할 수 있습니다. @Resource 주석을 사용하여 다음 매개변수를 지정할 수 있습니다.

  • lookup
  • name
  • mappedName

리소스를 주입하려면 이러한 매개변수 중 하나에서 리소스의 JNDI(Java Naming and Directory Interface) 이름을 지정해야 합니다.

31.8.1. 자카르타 메시징 리소스 삽입
링크 복사

  1. 다음과 같이 큐를 정의합니다. 

    <jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue"/>
    Copy to Clipboard Toggle word wrap

  2. @Resource 주석의 lookup, name 또는 mappedName 매개변수에 Java Naming 및 Directory Interface이름을 지정하여 이 큐를 주입합니다. 예를 들면 다음과 같습니다. 

    @Resource(lookup = "java:jboss/exported/jms/queue/OutQueue")
public Queue myOutQueue;
    Copy to Clipboard Toggle word wrap

31.8.2. 연결 팩트 삽입
링크 복사

  1. 연결 팩토리를 다음과 같이 정의합니다. 이 예제에서는 JmsXA 풀링된 연결 팩토리를 보여줍니다. 

    <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
    Copy to Clipboard Toggle word wrap

  2. 다음과 같이 default activemq-ra 풀링된 연결 팩토리를 주입합니다. 

    @Resource(lookup = "java:/JmsXA")
private ConnectionFactory cf;
    Copy to Clipboard Toggle word wrap

  • 자카르타 메시징 API는 자카르타 메시징 리소스를 생성하는 프로그래밍 방식을 제공하지 않으며 자카르타 메시징 2.0 사양에 정의된 기능만 지원됩니다. 사양에 대한 자세한 내용은 Jakarta Messaging 2.0 사양을 참조하십시오.

    • EE.5.18.4 자카르타 메시징 연결 팩토리 리소스 정의

      이는 애플리케이션이 자카르타 메시징 ConnectionFactory 리소스를 정의할 수 있는 기능입니다.

    • EE.5.18.5 자카르타 메시징 대상 정의

      이는 애플리케이션이 자카르타 메시징 대상 리소스를 정의하는 기능입니다.

32장. 이전 및 앞으로의 호환성
링크 복사

JBoss EAP는 HornetQ를 JBoss EAP와 같은 메시징 브로커로 사용하던 기존 버전의 JBoss EAP와 이전 버전과의 호환성을 모두 지원합니다. 이 두 가지 호환성 모드는 HornetQ의 코어 프로토콜을 지원하는 ActiveMQ Artemis의 기본 제공 메시징 서버인 ActiveMQ Artemis에서 제공합니다.

  • 전달 호환성: HornetQ를 사용하는 레거시 자카르타 메시징 클라이언트는 ActiveMQ Artemis를 실행하는 JBoss EAP 7 서버에 연결할 수 있습니다.
  • 이전 버전과 호환성: JBoss EAP 메시징을 사용하는 JBoss EAP 7 Jakarta Messaging 클라이언트는 HornetQ를 실행하는 레거시 JBoss EAP 6 서버에 연결할 수 있습니다.

32.1. 전달 호환성
링크 복사

전달 호환성에는 기존 JBoss EAP 6 Jakarta Messaging 클라이언트에 대한 코드 변경이 필요하지 않습니다. 지원은 JBoss EAP messaging-activemq 하위 시스템과 해당 리소스에서 제공합니다. 전달 호환성을 지원하려면 JBoss EAP 7 서버의 구성을 다음과 같이 변경합니다. 독립 실행형 서버에 대한 관리 CLI 명령 예제는 각 단계에 대해 제공됩니다.

  • 원격 레거시 클라이언트의 포트 4447에서 소켓 바인딩 을 만듭니다. 

    /socket-binding-group=standard-sockets/socket-binding=legacy-remoting:add(port=4447)
    Copy to Clipboard Toggle word wrap

  • 이전 단계에서 만든 socket-binding 을 사용할 레거시 원격 연결기를 만듭니다. 이는 JNDI 조회에 필요합니다. 

    /subsystem=remoting/connector=legacy-remoting-connector:add(socket-binding=legacy-remoting)
    Copy to Clipboard Toggle word wrap

  • 포트 5445에서 수신 대기 하는 레거시 메시징 소켓 바인딩을 설정합니다. 

    /socket-binding-group=standard-sockets/socket-binding=legacy-messaging:add(port=5445)
    Copy to Clipboard Toggle word wrap

  • 이전 단계의 바인딩을 사용하는 messaging - activemq 하위 시스템에서 remote- connector 및 remote-acceptor 를 설정합니다. 

    /subsystem=messaging-activemq/server=default/remote-connector=legacy-messaging-connector:add(socket-binding=legacy-messaging)

/subsystem=messaging-activemq/server=default/remote-acceptor=legacy-messaging-acceptor:add(socket-binding=legacy-messaging)
    Copy to Clipboard Toggle word wrap

  • messaging-activemq 하위 시스템의 legacy -connection-factory 요소에 레거시 HornetQ Jakarta Messaging ConnectionFactory를 만듭니다. 

    /subsystem=messaging-activemq/server=default/legacy-connection-factory=legacy-discovery:add(entries=[java:jboss/exported/jms/LegacyRemoteConnectionFactory], connectors=[legacy-messaging-connector])
    Copy to Clipboard Toggle word wrap

  • 레거시 HornetQ Jakarta Messaging 대상을 만들고 jms - queue 또는 jms- topic 리소스에 legacy- entries 속성을 포함합니다. 

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

jms-topic add --topic-address=myTopic --entries=[java:jboss/exported/jms/myTopic-new] --legacy-entries=[java:jboss/exported/jms/myTopic]
    Copy to Clipboard Toggle word wrap

    아래 예제에 따라 기존 대기열 또는 토픽에 legacy-entries 를 추가할 수 있습니다. 

    /subsystem=messaging-activemq/server=default/jms-queue=myQueue:write-attribute(name=legacy-entries,value=[java:jboss/exported/jms/myQueue])
    Copy to Clipboard Toggle word wrap

    entry 특성은 JBoss EAP 메시징 메시징 클라이언트에서 사용하지만 legacy-entries 는 레거시 HornetQ Jakarta Messaging 클라이언트에서 사용합니다. 레거시 Jakarta Messaging 클라이언트는 JBoss EAP 7과 통신하기 위해 레거시 Jakarta Messaging 리소스를 조회합니다.

    참고

    레거시 Jakarta Messaging 클라이언트의 코드 변경 사항을 방지하려면 messaging-activemq 하위 시스템에서 구성된 레거시 JNDI 항목이 레거시 Jakarta Messaging 클라이언트에서 예상되는 조회와 일치해야 합니다.

관리 CLI 마이그레이션 작업

관리 CLI migrate 작업을 실행하여 메시징 하위 시스템 구성을 업데이트할 때 부울 인수 add-legacy-entries 가 true 로 설정된 경우 messaging-activemq 하위 시스템은 legacy-connection-factory 리소스를 생성하고 legacy-entries 를 jms-queue 및 jms-topic 리소스에 추가합니다. 마이그레이션된 messaging-activemq 하위 시스템의 레거시 항목은 레거시 메시징 하위 시스템에 지정된 항목에 해당하며 일반 항목은 -new 접미사로 생성됩니다.

마이그레이션 작업을 실행할 때 부울 인수 add-legacy-entries 가 false 로 설정된 경우 messaging-activemq 하위 시스템에서 레거시 리소스가 생성되지 않으며 레거시 Jakarta Messaging 클라이언트는 JBoss EAP 7 서버와 통신할 수 없습니다.

32.2. 이전 호환성
링크 복사

이전 버전과의 호환성을 위해 레거시 JBoss EAP 7 서버에서 구성을 변경할 필요가 없습니다. JBoss EAP 7 Jakarta Messaging 클라이언트는 기존 서버에서 리소스를 찾지 않고 클라이언트 측 JNDI를 사용하여 자카르타 메시징 리소스를 생성합니다. JBoss EAP 7 Jakarta Messaging 클라이언트는 이러한 리소스를 사용하여 HornetQ 코어 프로토콜을 사용하여 레거시 서버와 통신할 수 있습니다.

주의

JBoss EAP 5 서버에 대한 JBoss EAP 7 클라이언트 연결은 현재 지원되지 않습니다.

JBoss EAP 메시징은 클라이언트 측 JNDI를 지원하여 자카르타 메시징 ConnectionFactory 및 대상 리소스를 생성합니다.

예를 들어 JBoss EAP 7 Jakarta Messaging 클라이언트가 "myQueue"라는 자카르타 메시징 큐를 사용하여 기존 서버와 통신하려는 경우 다음 속성을 사용하여 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
Copy to Clipboard Toggle word wrap

그런 다음 클라이언트는 jms/ConnectionFactory 이름을 사용하여 Jakarta Messaging ConnectionFactory 를 생성하고 jms/myQueue 를 사용하여 자카르타 메시징 대기열 을 생성할 수 있습니다. 레거시 연결 팩토리의 URL을 지정할 때 protocolManagerFactoryStr=org.apache.activemq.artemis.core.protocol.wonetq.client.HornetQClientProtocolManagerFactory 속성이 필요합니다. 이를 통해 JBoss EAP 메시징 자카르타 메시징 클라이언트에서 레거시 서버의 HornetQ 브로커와 통신할 수 있습니다.

IV 부. 성능 튜닝
링크 복사

33장. 메시징 통계 모니터링
링크 복사

messaging-activemq 하위 시스템에서 메시징 서버에 대한 통계 수집을 활성화하면 메시징 서버의 리소스에 대한 런타임 통계를 볼 수 있습니다.

33.1. 메시징 통계 활성화
링크 복사

성능에 부정적인 영향을 줄 수 있기 때문에 messaging-activemq 하위 시스템의 통계 컬렉션은 기본적으로 활성화되어 있지 않습니다. 대기열의 메시지 수 또는 큐에 추가된 메시지 수와 같은 기본 정보를 얻기 위해 대기열 통계를 활성화할 필요가 없습니다. 이러한 통계는 통계를 true 로 설정하지 않고도 큐 특성을 사용하여 사용할 수 있습니다.

관리 CLI 또는 관리 콘솔을 사용하여 추가 통계 컬렉션을 활성화할 수 있습니다.

관리 CLI를 사용하여 메시징 통계 활성화

다음 관리 CLI 명령은 기본 메시징 서버에 대한 통계 컬렉션을 활성화합니다. 

/subsystem=messaging-activemq/server=default:write-attribute(name=statistics-enabled,value=true)
Copy to Clipboard Toggle word wrap

풀링된 연결 팩토리 통계는 다른 메시징 서버 통계와 별도로 활성화됩니다. 다음 명령을 사용하여 풀링된 연결 팩토리에 대한 통계를 활성화합니다. 

/subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=statistics-enabled,value=true)
Copy to Clipboard Toggle word wrap

변경 사항을 적용하려면 서버를 다시 로드합니다.

관리 콘솔을 사용하여 메시징 통계 활성화

관리 콘솔을 사용하여 메시징 서버에 대한 통계 컬렉션을 활성화하려면 다음 단계를 사용합니다.

  1. Configuration → Subsystems → Messaging (ActiveMQ) → 서버로 이동합니다.
  2. 서버를 선택하고 View(보기 )를 클릭합니다.
  3. Statistics (통계) 탭에서 Edit (편집)를 클릭합니다.
  4. Statistics Enabled(통계 활성화됨) 필드를 ON (켜짐)으로 설정하고 Save(저장 )를 클릭합니다.

풀링된 연결 팩토리 통계는 다른 메시징 서버 통계와 별도로 활성화됩니다. 다음 단계를 사용하여 풀링된 연결 팩토리에 대한 통계 컬렉션을 활성화합니다.

  1. Configuration → Subsystems → Messaging (ActiveMQ) → 서버로 이동합니다.
  2. 서버를 선택하고 Connections (연결)를 선택한 다음 View(보기 )를 클릭합니다.
  3. Pooled Connection factory(풀링 연결 팩토리 ) 탭을 선택합니다.
  4. pooled 연결 팩토리를 선택하고 Attributes (특성) 탭에서 Edit(편집 )를 클릭합니다.
  5. Statistics Enabled(통계 활성화됨) 필드를 ON (켜짐)으로 설정하고 Save(저장 )를 클릭합니다.
  6. 변경 사항을 적용하려면 서버를 다시 로드합니다.

33.2. 메시징 통계 보기
링크 복사

관리 CLI 또는 관리 콘솔을 사용하여 메시징 서버에 대한 런타임 통계를 볼 수 있습니다.

관리 CLI를 사용하여 메시징 통계 보기

다음 관리 CLI 명령을 사용하여 메시징 통계를 볼 수 있습니다. 통계가 런타임 정보이므로 include-runtime=true 인수를 포함해야 합니다.

  • 큐에 대한 통계 보기. 

    /subsystem=messaging-activemq/server=default/jms-queue=DLQ:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "consumer-count" => 0,
        "dead-letter-address" => "jms.queue.DLQ",
        "delivering-count" => 0,
        "durable" => true,
        ...
    }
}
    Copy to Clipboard Toggle word wrap

  • 항목에 대한 통계 보기. 

    /subsystem=messaging-activemq/server=default/jms-topic=testTopic:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "delivering-count" => 0,
        "durable-message-count" => 0,
        "durable-subscription-count" => 0,
        ...
    }
}
    Copy to Clipboard Toggle word wrap

  • 풀링된 연결 팩토리에 대한 통계를 봅니다. 

    /subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra/statistics=pool:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "ActiveCount" => 1,
        "AvailableCount" => 20,
        "AverageBlockingTime" => 0L,
        "AverageCreationTime" => 13L,
        "AverageGetTime" => 14L,
        ...
    }
}
    Copy to Clipboard Toggle word wrap
    참고

    풀링된 연결 팩토리 통계는 다른 메시징 서버 통계와 별도로 활성화됩니다. 지침은 메시징 통계 활성화 를 참조하십시오.

관리 콘솔을 사용하여 메시징 통계 보기

관리 콘솔에서 메시징 통계를 보려면 Runtime (런타임) 탭에서 Messaging (ActiveMQ) 하위 시스템으로 이동하여 서버를 선택합니다. 통계를 보려면 대상을 선택합니다.

참고

준비된 트랜잭션 페이지는 준비된 트랜잭션을 보고, 커밋 및 롤백할 수 있는 위치입니다. 자세한 내용은 메시징 저널 준비 트랜잭션 관리를 참조하십시오.

사용 가능한 모든 통계에 대한 자세한 목록은 메시징 통계를 참조하십시오.

33.3. 메시지 카운터 구성
링크 복사

메시징 서버에 대해 다음 메시지 카운터 특성을 구성할 수 있습니다.

  • message-counter-max-day-history: 메시지 카운터 기록이 유지되는 일 수입니다.
  • message-counter-sample-period: 밀리초 단위로 대기열을 샘플링하는 빈도입니다.

관리 CLI 명령은 이러한 옵션을 구성하는 데 다음 구문을 사용합니다. STATIST _NAME 및 STAT IST¢_VALUE 를 구성하려는 통계 이름과 값으로 교체해야 합니다. 

/subsystem=messaging-activemq/server=default::write-attribute(name=STATISTICS_NAME,value=STATISTICS_VALUE)
Copy to Clipboard Toggle word wrap

예를 들어 다음 명령을 사용하여 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)
Copy to Clipboard Toggle word wrap

33.4. 대기열에 대한 메시지 카운터 및 기록 보기
링크 복사

다음 관리 CLI 작업을 사용하여 큐의 메시지 카운터 및 메시지 카운터 기록을 볼 수 있습니다.

  • list-message-counter-as-json
  • list-message-counter-as-html
  • list-message-counter-history-as-json
  • list-message-counter-history-as-html

관리 CLI 명령으로 이러한 값을 표시하려면 다음 구문을 사용합니다. QUEUE_NAME 및 OPERATION_ NAME 을 사용하려는 큐 이름 및 작업으로 교체해야 합니다. 

/subsystem=messaging-activemq/server=default/jms-queue=QUEUE_NAME:OPERATION_NAME
Copy to Clipboard Toggle word wrap

예를 들어 다음 명령을 사용하여 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\"}"
}
Copy to Clipboard Toggle word wrap

33.5. 큐에 대한 메시지 카운터 재설정
링크 복사

reset -message-counter 관리 CLI 작업을 사용하여 큐에 대한 메시지 카운터를 재설정할 수 있습니다. 

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

33.6. 관리 콘솔을 사용한 런타임 작업
링크 복사

관리 콘솔을 사용하여 다음을 수행할 수 있습니다.

  • 다른 메시징 서버로의 강제 페일오버 수행
  • 메시징 서버의 모든 메시지 카운터 재설정
  • 메시징 서버의 모든 메시지 카운터 기록 재설정
  • 메시징 서버와 관련된 정보 보기
  • 메시징 서버 연결 닫기
  • 트랜잭션 롤백
  • 트랜잭션 커밋
다른 메시징 서버로 강제 페일오버 수행

  1. 관리 콘솔에 액세스하고 다음 중 하나를 사용하여 Server 로 이동합니다.

    • 런타임→ 찾아보기 → 호스트 → 서버
    • 런타임→ 찾아보기 → 서버 그룹 → 서버 그룹 → 서버
  2. 메시징 ActiveMQ → 서버클릭
  3. View (보기) 옆에 있는 화살표 버튼을 클릭하고 Force Failover (강제 실패)를 클릭합니다.
  4. Force Failover(강제 Failover ) 창에서 Yes (예)를 클릭합니다.
메시징 서버의 모든 메시지 카운터 재설정

  1. 관리 콘솔에 액세스하고 다음 중 하나를 사용하여 Server 로 이동합니다.

    • 런타임→ 찾아보기 → 호스트 → 서버
    • 런타임→ 찾아보기 → 서버 그룹 → 서버 그룹 → 서버
  2. 메시징 ActiveMQ → 서버클릭
  3. View (보기) 옆에 있는 화살표 버튼을 클릭하고 Reset(재설정 )을 클릭합니다.

  4. Reset(재설정) 창에서 Reset all message counters(모든 메시지 카운터 재설정) 옆의 토글 버튼을 클릭하여 기능을 활성화합니다.

    이제 버튼이 파란색 바탕에 ON 으로 표시됩니다.

  5. Reset(재설정 )을 클릭합니다.
메시징 서버에 대한 메시지 카운터 기록 재설정

  1. 관리 콘솔에 액세스하고 다음 중 하나를 사용하여 Server 로 이동합니다.

    • 런타임→ 찾아보기 → 호스트 → 서버
    • 런타임→ 찾아보기 → 서버 그룹 → 서버 그룹 → 서버
  2. 메시징 ActiveMQ → 서버클릭
  3. View (보기) 옆에 있는 화살표 버튼을 클릭하고 Reset(재설정 )을 클릭합니다.

  4. Reset(재설정) 창에서 Reset ( 모든 메시지 카운터) 기록 재설정 옆에 있는 토글 버튼을 클릭하여 기능을 활성화합니다.

    이제 버튼이 파란색 바탕에 ON 으로 표시됩니다.

  5. Reset(재설정 )을 클릭합니다.
메시징 서버와 관련된 정보 보기

관리 콘솔을 사용하여 메시징 서버와 관련된 다음 정보 목록을 볼 수 있습니다.

  • 연결
  • 소비자
  • 생산자
  • 커넥터
  • 역할
  • 트랜잭션

메시징 서버와 관련된 정보를 보려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스하고 다음 중 하나를 사용하여 Server 로 이동합니다.

    • 런타임→ 찾아보기 → 호스트 → 서버
    • 런타임→ 찾아보기 → 서버 그룹 → 서버 그룹 → 서버
  2. Messaging ActiveMQ → Server 를 클릭한 다음 View(보기 )를 클릭합니다.
  3. 네비게이션 창에서 해당 항목을 클릭하여 오른쪽 창의 항목 목록을 봅니다.
메시징 서버 연결 닫기

IP 주소, ActiveMQ 주소 일치 또는 사용자 이름을 제공하여 연결을 종료할 수 있습니다.

메시징 서버 연결을 닫으려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스하고 다음 중 하나를 사용하여 Server 로 이동합니다.

    • 런타임→ 찾아보기 → 호스트 → 서버
    • 런타임→ 찾아보기 → 서버 그룹 → 서버 그룹 → 서버
  2. Messaging ActiveMQ → Server 를 클릭한 다음 View(보기 )를 클릭합니다.
  3. 탐색 창에서 Connections (연결)를 클릭합니다.
  4. Close(닫기 ) 창에서 닫을 연결을 기준으로 적절한 탭을 클릭합니다.
  5. 선택 사항에 따라 IP 주소, ActiveMQ 주소 일치 또는 사용자 이름을 입력한 다음 Close(닫기 )를 클릭합니다.
메시징 서버의 백 트랜잭션 롤링

  1. 관리 콘솔에 액세스하고 다음 중 하나를 사용하여 Server 로 이동합니다.

    • 런타임→ 찾아보기 → 호스트 → 서버
    • 런타임→ 찾아보기 → 서버 그룹 → 서버 그룹 → 서버
  2. Messaging ActiveMQ → Server 를 클릭한 다음 View(보기 )를 클릭합니다.
  3. 네비게이션 창에서 Transactions(거래 )를 클릭합니다.
  4. 롤백할 트랜잭션을 선택하고 롤백 을 클릭합니다.
메시징 서버에 대한 트랜잭션 커밋

  1. 관리 콘솔에 액세스하고 다음 중 하나를 사용하여 Server 로 이동합니다.

    • 런타임→ 찾아보기 → 호스트 → 서버
    • 런타임→ 찾아보기 → 서버 그룹 → 서버 그룹 → 서버
  2. Messaging ActiveMQ → Server 를 클릭한 다음 View(보기 )를 클릭합니다.
  3. 네비게이션 창에서 Transactions(거래 )를 클릭합니다.
  4. 커밋할 트랜잭션을 선택하고 Commit(커밋 )을 클릭합니다.

34장. 자카르타 메시징 조정
링크 복사

Jakarta Messaging API를 사용하는 경우 성능 향상 방법에 대한 팁은 다음 정보를 확인하십시오.

  • 메시지 ID를 비활성화합니다.

    메시지 ID가 필요하지 않은 경우 MessageProducer 클래스에서 setDisableMessageID() 메서드를 사용하여 비활성화합니다. 값을 true 로 설정하면 고유한 ID를 생성하는 오버헤드가 제거되고 메시지 크기가 줄어듭니다.

  • 메시지 타임스탬프를 비활성화합니다.

    메시지 타임스탬프가 필요하지 않은 경우 MessageProducer 클래스에서 setDisableMessageTimeStamp() 메서드를 사용하여 비활성화합니다. 값을 true 로 설정하면 타임스탬프 생성에 대한 오버헤드가 제거되고 메시지 크기가 줄어듭니다.

  • ObjectMessage 를 사용하지 마십시오.

    ObjectMessage 는 메시지 본문 또는 페이로드를 나타내는 직렬화된 개체가 포함된 메시지를 바이트 스트림으로 전송하는 데 사용됩니다. 소규모 객체의 Java 직렬화 형태는 상당히 크며, 와이어에 많은 공간을 차지합니다. 또한 사용자 지정 마샬링 기술과 비교할 때 속도가 느립니다. 예를 들어 런타임까지 페이로드 유형을 모르는 경우와 같이 다른 메시지 유형 중 하나를 사용할 수 없는 경우에만 ObjectMessage 를 사용합니다.

  • 차단 (_ACKNOWLEDGE ).

    소비자의 승인 모드를 선택하면 네트워크를 통해 전송된 승인 메시지를 전송하여 발생하는 추가 오버헤드 및 트래픽 때문에 성능에 영향을 미칩니다. 클라이언트에서 수신한 각 메시지에 대해 서버에서 승인을 보내야 하므로 이 오버헤드가 발생하여 이 오버헤드가 발생합니다. 지연된 방식으로 메시지를 인식하는 DUPS_OK_ACKNOWLEDGE 를 사용할 수 있는 경우 CLIENT_ACKNOWLEDGE 를 사용합니다. 즉, 클라이언트 코드가 메시지를 인정하는 메서드를 호출하거나 트랜잭션된 세션에서 하나의 승인 또는 커밋으로 많은 감사를 일괄 처리합니다.

  • 지속적 메시지 방지.

    기본적으로 자카르타 메시징 메시지는 지속적입니다. 지속적 메시지가 필요하지 않은 경우 복구 불가로 설정합니다. 지속적 메시지는 스토리지에 지속되므로 많은 오버헤드가 발생합니다.

  • TRANSACTED_SESSION 모드를 사용하여 단일 트랜잭션에서 메시지를 보내고 받습니다.

    JBoss EAP에 통합된 ActiveMQ Artemis 서버에는 단일 트랜잭션으로 메시지를 배치하면 모든 전송 또는 수신이 아닌 커밋에 하나의 네트워크 왕복만 필요합니다.

35장. 지속성 튜닝
링크 복사

  • 메시지 저널을 자체 물리 볼륨에 둡니다.

    추가 전용 저널의 장점 중 하나는 디스크 헤드 이동이 최소화된다는 것입니다. 디스크를 공유하면 이러한 이점이 손실됩니다. 트랜잭션 코디네이터, 데이터베이스 및 기타 저널과 같은 여러 프로세스가 동일한 디스크에서 읽고 쓰는 경우 다른 파일 간에 디스크 헤드를 건너뛰어야 하므로 성능에 영향을 미칩니다. 페이징 또는 대용량 메시지를 사용하는 경우 별도의 볼륨에도 배치되었는지 확인합니다.

  • journal-min-files 값을 조정합니다.

    journal-min-files 매개변수를 평균 지속 가능한 속도에 맞는 파일 수로 설정합니다. 저널 데이터 디렉터리에서 생성되는 새 파일이 자주 표시되는 경우 많은 데이터가 유지되는 경우 최소한의 파일 수를 늘려야 합니다. 이를 통해 저널은 새 데이터 파일을 생성하는 대신 다시 사용할 수 있습니다.

  • 저널 파일 크기를 최적화합니다.

    저널 파일 크기는 디스크의 Workspace 용량에 맞게 조정되어야 합니다. 대부분의 시스템에서 기본값 10MB 를 충분해야 합니다.

  • AIO 저널 유형을 사용합니다.

    Linux 운영 체제의 경우 저널 유형을 AIO 로 유지합니다. AIO 는 Java NIO보다 확장성이 우수합니다.

  • journal-buffer-timeout 값을 조정합니다.

    journal-buffer-timeout 값을 늘리면 대기 시간을 희생하면서 처리량이 증가합니다.

  • journal-max-io 값을 조정합니다.

    AIO 를 사용하는 경우 journal-max-io 매개변수 값을 늘려 성능을 향상시킬 수 있습니다. NIO 를 사용하는 경우 이 값을 변경하지 마십시오.

36장. 기타 튜닝 옵션
링크 복사

이 섹션에서는 조정할 수 있는 JBoss EAP 메시징의 다른 위치에 대해 설명합니다.

  • 비동기식 전송 승인 사용.

    트랜잭션이 아닌 지속적 메시지를 보내야 하며 send ()가 반환될 때까지 서버에 연결했다는 보장이 필요하지 않은 경우 차단을 보내도록 설정하지 마십시오. 대신 비동기식 보내기 감사를 사용하여 별도의 스트림에서 반환된 감사 인사를 가져옵니다. 그러나 서버 충돌의 경우 일부 메시지가 손실될 수 있습니다.

  • 사전 잠금 모드 사용.

    Pre-acknowledge 모드를 사용하면 메시지가 클라이언트로 전송되기 전에 메시지가 승인됩니다. 이렇게 하면 유선의 승인 트래픽 양이 줄어듭니다. 그러나 해당 클라이언트가 충돌하면 클라이언트가 다시 연결하면 메시지가 다시 전송되지 않습니다.

  • 보안 비활성화.

    security -enabled 특성을 false로 설정하여 보안을 비활성화하면 작은 성능 향상이 있습니다.

  • 지속성을 비활성화합니다.

    지속성을 false 로 설정하여 메시지 지속성을 완전히 끌 수 있습니다.

  • 지연된 트랜잭션 동기화.

    journal-sync-transactional 을 false 로 설정하면 실패 시 트랜잭션이 손실될 가능성이 있는 경우 트랜잭션 지속 성능이 향상됩니다.

  • 트랜잭션이 아닌 지연 동기화.

    journal-sync-non-transactional 을 false 로 설정하면 오류가 발생했을 때 지속적 메시지가 손실될 수 있으므로 트랜잭션이 유지되지 않는 지속적인 성능이 향상됩니다.

  • 차단되지 않은 메시지 보내기.

    Jakarta Messaging 및 JNDI를 사용하는 경우 전송된 모든 메시지에 대해 네트워크 왕복을 기다리지 않고 block-on-durable-send 및 block-on-durable-send를 false로 설정하거나 setBlockOnNonDurableSend() 메서드를 호출하여 ServerLocator 에 직접 설정합니다.

  • consumer-window-size 를 최적화합니다.

    매우 빠른 소비자가 있는 경우 consumer-window-size 를 늘려 소비자 흐름 제어를 효과적으로 비활성화할 수 있습니다.

  • Jakarta Messaging API 대신 코어 API를 사용합니다.

    Jakarta Messaging 작업은 서버가 처리할 수 있으려면 핵심 작업으로 변환해야 하므로 코어 API를 사용할 때보다 성능이 저하됩니다. 핵심 API를 사용하는 경우 SimpleString 을 최대한 사용하는 방법을 사용하십시오. java.lang.String 과 달리 Simple String 은 유선에 쓰기 전에 복사할 필요가 없으므로 호출 간에 SimpleString 인스턴스를 재사용하면 불필요한 복사를 방지할 수 있습니다. 코어 API는 다른 브로커에 이식할 수 없습니다.

37장. Ptterns 방지
링크 복사

  • 가능한 경우 연결, 세션, 소비자 및 생산자를 재사용합니다.

    가장 일반적인 메시징 방지 패턴은 전송되거나 사용되는 모든 메시지에 대해 새 연결, 세션 및 생산자를 생성하는 것입니다. 이러한 개체는 생성하는 데 시간이 걸리며 여러 네트워크 왕복 작업이 수반될 수 있으므로 리소스를 잘못 사용하는 것입니다. 항상 재사용합니다.

    참고

    Spring Messaging 템플릿과 같은 일부 인기 있는 라이브러리는 이러한 유사성 방지를 사용합니다. Spring Messaging Template을 사용하는 경우 성능이 저하될 수 있습니다. Spring Messaging Template은 Jakarta Connectors를 사용하는 등 Jakarta Messaging 세션을 캐시하는 애플리케이션 서버에서만 안전하게 사용할 수 있으며 그 후에만 메시지를 전송할 수 있습니다. 애플리케이션 서버에서도 메시지를 동기적으로 사용하는 데 안전하게 사용할 수 없습니다.

  • 부정적 메시지 방지.

    XML과 같은 자세한 형식은 유선으로 많은 공간을 차지하며 결과적으로 성능이 저하됩니다. 가능한 경우 메시지 본문에서 XML을 방지합니다.

  • 요청마다 임시 큐를 생성하지 마십시오.

    이러한 일반적인 패턴에는 임시 큐 요청 응답 패턴이 포함됩니다. 임시 큐 request-response 패턴을 사용하면 메시지가 타겟으로 전송되고 reply-to 헤더는 로컬 임시 큐의 주소로 설정됩니다. 수신자가 메시지를 수신하면 메시지를 처리한 다음 reply-to 헤더에 지정된 주소로 응답을 보냅니다. 이 패턴으로 인한 일반적인 실수는 전송된 각 메시지에 새 임시 대기열을 만드는 것입니다. 그러면 성능이 크게 저하됩니다. 대신 많은 요청에 대해 임시 큐를 재사용해야 합니다.

  • 필요하지 않으면 메시지 기반 빈을 사용하지 마십시오.

    MDB를 사용하여 메시지를 사용하는 것은 간단한 자카르타 메시징 메시지 소비자를 사용하여 메시지를 사용하는 것보다 더 느립니다.

부록 A. 참고 자료
링크 복사

A.1. 주소 설정 속성
링크 복사

Expand
표 A.1. 주소 설정 속성
이름설명

address-full-policy

max-size-bytes 가 지정된 주소가 가득 차면 어떤 일이 발생하는지 결정합니다. 허용되는 값은 PAGE,DROP,FAIL, BLOCK 입니다. 값이 PAGE 이면 추가 메시지가 디스크로 호출됩니다. 값이 DROP 이면 추가 메시지가 자동으로 삭제됩니다. 값이 FAIL 이면 메시지가 삭제되고 클라이언트 메시지 생산자는 예외를 받습니다. 값이 BLOCK 이면 클라이언트 메시지 생산자가 추가 메시지를 시도하고 보낼 때 차단됩니다. PAGE 가 기본값입니다. 페이징에 대한 자세한 내용은 페이징 정보를 참조하십시오.

auto-create-jms-queues

자카르타 메시징 생산자 또는 소비자가 이러한 큐를 사용하려고 할 때 주소 설정에 해당하는 자카르타 메시징 큐를 자동으로 생성해야 하는지 여부를 결정합니다. 기본값은 false입니다. 더 이상 사용되지 않음: 대신 auto-create-queues 를 사용합니다.

auto-create-jms-topics

자카르타 메시징 생산자 또는 소비자가 이러한 큐를 사용하려고 할 때 주소 설정에 해당하는 Jakarta Messaging 주제를 자동으로 생성해야 하는지 여부를 결정합니다. 기본값은 false입니다. 더 이상 사용되지 않음: 대신 auto-create-addresses 를 사용합니다.

auto-create-addresses

메시지가 전송될 때 브로커가 주소를 자동으로 생성해야 하는지 또는 소비자가 주소가 일치하는 이름과 일치하는 큐에 연결을 시도하는지 여부를 결정합니다. 자동 생성된 대기열은 지속적, 비임시적 및 일시적이지 않은 대기열입니다. 기본값은 true입니다.

auto-create-queues

메시지가 전송될 때 브로커가 대기열을 자동으로 생성해야 하는지 또는 소비자가 주소가 일치하는 이름과 일치하는 큐에 연결을 시도하는지 여부를 결정합니다. 자동 생성된 대기열은 지속적, 비임시적 및 일시적이지 않은 대기열입니다. 기본값은 true입니다.

auto-delete-jms-queues

JBoss EAP가 소비자가 없고 메시지가 없는 경우 자동 생성된 자카르타 메시징 대기열을 자동으로 삭제해야 하는지 여부를 결정합니다. 기본값은 false입니다. 더 이상 사용되지 않음: 대신 auto-delete-queues 를 사용합니다.

auto-delete-jms-topics

JBoss EAP가 소비자가 없고 메시지가 없는 경우 자동 생성된 자카르토리 메시징 주제를 자동으로 삭제해야 하는지 여부를 결정합니다. 기본값은 false입니다. 더 이상 사용되지 않음: 대신 auto-delete-addresses 를 사용합니다.

auto-delete-addresses

주소에 더 이상 큐가 없으면 브로커가 자동 생성된 주소를 자동으로 삭제해야 하는지 여부를 결정합니다. 기본값은 true입니다.

auto-delete-queues

소비자와 0 개 메시지가 모두 있는 경우 브로커가 자동 생성된 큐를 자동으로 삭제해야 하는지 여부를 결정합니다. 기본값은 true입니다.

dead-letter-address

배달된 메시지를 보낼 주소입니다. 자세한 내용은 배달 못 한 편지 주소 구성을 참조하십시오.

expiry-address

만료된 메시지를 수신할 주소입니다. 자세한 내용은 메시지 만료 구성을 참조하십시오.

expiry-delay

기본 만료 시간을 사용하여 메시지에 사용할 만료 시간(밀리초)을 정의합니다. 기본값은 -1 입니다.

last-value-queue

큐에서 마지막 값만 사용하는지 여부를 정의합니다. 자세한 내용은 Last-value Queues 를 참조하십시오.

max-delivery-attempts

취소된 메시지를 dead-letter-address로 보내기 전에 재전송할 수 있는 시간을 정의합니다. 기본값은 10 입니다.

max-redelivery-delay

redelivery-delay의 최대값(밀리초). 기본값은 0 입니다.

max-size-bytes

이 주소의 최대 크기(바이트)입니다. 기본값은 -1 입니다.

message-counter-history-day-limit

메시지 카운터 기록의 일 제한입니다. 기본값은 0 입니다.

page-max-cache-size

페이징 탐색 중에 IO를 최적화하기 위해 메모리에 보관할 페이지 파일 수입니다. 기본값은 5 입니다.

page-size-bytes

페이징 크기(바이트)입니다. 기본값은 10485760 입니다.

redelivery-delay

취소된 메시지의 재배달을 시도하기 전에 대기하는 시간(밀리초)을 정의합니다. 기본값은 0 입니다. 자세한 내용은 지연된 재배달 구성을 참조하십시오.

redelivery-multiplier

redelivery-delay 매개변수에 적용되는 승수입니다. 기본값은 1.0 입니다.

redistribution-delay

메시지를 재배포하기 전에 마지막 소비자가 큐에서 닫힌 후(밀리초) 대기할 시간을 정의합니다. 기본값은 -1 입니다.

send-to-dla-on-no-route

true 로 설정하면 큐로 라우팅할 수 없는 경우 구성된 배달 못 한 주소로 메시지가 전송됩니다. 기본값은 false 입니다.

slow-consumer-check-period

느린 소비자에 대해 확인하는 빈도(초)입니다. 기본값은 5 입니다.

slow-consumer-policy

느린 소비자를 식별할 때 발생하는 상황을 결정합니다. 유효한 옵션은 KILL 이거나 NOTIFY 입니다. KILL 은 소비자 연결을 종료하여 동일한 연결을 사용하는 모든 클라이언트 스레드에 영향을 미칩니다. NOTIFY 는 CONSUMER_SLOW 관리 알림을 클라이언트에 보냅니다. 기본값은 NOTIFY 입니다.

slow-consumer-threshold

소비자가 느리기 전에 허용되는 최소 메시지 사용률입니다. 기본값은 -1 입니다.

A.2. 연결 팩토리 속성
링크 복사

Expand
표 A.2. 연결 팩토리 속성
속성설명

auto-group

메시지 그룹화가 자동으로 사용되는지 여부.

block-on-acknowledge

승인을 차단할지 여부.

block-on-durable-send

지속적 전송에서 차단할지 여부입니다.

block-on-non-durable-send

지속되지 않는 전송에서 차단할지 여부입니다.

cache-large-message-client

대용량 메시지 캐시 여부.

call-failover-timeout

페일오버가 프로세스 중일 때 사용할 시간(밀리초)입니다.

call-timeout

호출 시간 초과(밀리초).

client-failure-check-period

클라이언트 오류 검사 기간(밀리초)입니다.

client-id

클라이언트 ID입니다.

compress-large-messages

큰 메시지를 압축해야 하는지 여부.

confirmation-window-size

확인 창 크기(바이트)입니다.

connection-load-balancing-policy-class-name

클라이언트에서 클러스터의 여러 노드에 걸쳐 세션을 부하 분산하는 데 사용할 수 있는 클라이언트 측 부하 분산 정책을 구현하는 클래스의 이름입니다.

connection-ttl

수명(밀리초)입니다.

커넥터

커넥터 이름(정의되지 않은 값)에 따라 맵에 저장되는 커넥터를 정의합니다. 이 특성을 작성할 때 커넥터 이름 목록을 전달할 수 있습니다.

consumer-max-rate

소비자 최대 속도(초당).

consumer-window-size

소비자 창 크기(바이트)입니다.

deserialization-black-list

역직렬화할 수 없는 클래스 또는 패키지 목록을 정의합니다.

deserialization-white-list

역직렬화할 수 있는 클래스 또는 패키지 목록을 정의합니다.

discovery-group

검색 그룹 이름입니다.

dups-ok-batch-size

dup ok 배치 크기.

enable-amq1-prefix

Jakarta Messaging 대상 이름에 접두사를 포함할지 여부를 지정합니다. 값이 false이면 접두사가 포함되지 않습니다.

항목

연결 팩토리에 바인딩해야 하는 JNDI 이름입니다.

factory-type

연결 팩토리의 유형입니다. 유효한 값은 다음과 같습니다.

  • 일반
  • TOPIC
  • QUEUE
  • XA_GENERIC
  • XA_QUEUE
  • XA_TOPIC

GENERIC 을 브로커에 대한 일반적인 연결에는 사용하지만, IC 및 QUEUE 는 해당 자카르타 메시징 유형 연결에 사용해야 합니다. XA 대응자는 트랜잭션 메시징에 사용해야 합니다.

failover-on-initial-connection

초기 연결 시 페일오버 여부를 지정합니다.

group-id

그룹 ID입니다.

Ha

연결 팩토리가 고가용성을 지원하는지 여부.

max-retry-interval

최대 재시도 간격(밀리초)입니다.

min-large-message-size

최소 큰 메시지 크기(바이트)입니다.

pre-acknowledge

미리 파악해야 하는지 여부.

producer-max-rate

생산자 최대 속도(초당).

producer-window-size

생산자 창 크기(바이트)입니다.

protocol-manager-factory

이 연결 팩토리에서 사용하는 프로토콜 관리자 팩토리입니다.

reconnect-attempts

재연결 시도.

retry-interval

재시도 간격(밀리초)입니다.

retry-interval-multiplier

재시도 간격 승수.

scheduled-thread-pool-max-size

예약된 스레드 풀 최대 크기입니다.

thread-pool-max-size

스레드 풀 최대 크기입니다.

transaction-batch-size

트랜잭션 배치 크기입니다.

use-global-pools

글로벌 풀 사용 여부.

use-topology-for-load-balancing

메시징 클라이언트가 클러스터 토폴로지를 사용하여 클러스터에 연결할지 또는 모든 연결에 초기 커넥터를 사용할지 여부를 지정합니다.

A.3. 풀링된 연결 팩토리 속성
링크 복사

Expand
표 A.3. 풀링된 연결 팩토리 속성
속성설명

allow-local-transactions

아웃바운드 자카르타 메시징 세션의 로컬 트랜잭션 허용 여부.

true 로 설정하면 자카르타 메시징 생산자가 다음과 같은 상황에서 메시지를 보낼 수 있습니다.

  • 트랜잭션된 세션의 서블릿.
  • NOT_SUPPORTED 로 설정된 트랜잭션 유형 특성이 있는 트랜잭션 세션의 MDB에서.

이 특성은 JMSContext 에 적용되지 않으므로 명시적으로 허용하지 않습니다.

auto-group

메시지 그룹화가 자동으로 사용되는지 여부.

block-on-acknowledge

승인을 차단할지 여부.

block-on-durable-send

지속적 전송에서 차단할지 여부입니다.

block-on-non-durable-send

지속되지 않는 전송에서 차단할지 여부입니다.

cache-large-message-client

대용량 메시지 캐시 여부.

call-failover-timeout

페일오버가 프로세스 중일 때 사용할 시간(밀리초)입니다.

call-timeout

호출 시간 초과(밀리초).

client-failure-check-period

클라이언트 오류 검사 기간(밀리초)입니다.

client-id

클라이언트 ID입니다.

compress-large-messages

큰 메시지를 압축해야 하는지 여부.

confirmation-window-size

확인 창 크기(바이트)입니다.

connection-load-balancing-policy-class-name

클라이언트에서 클러스터의 여러 노드에 걸쳐 세션을 부하 분산하는 데 사용할 수 있는 클라이언트 측 부하 분산 정책을 구현하는 클래스의 이름입니다.

connection-ttl

수명(밀리초)입니다.

커넥터

커넥터 이름(정의되지 않은 값)에 따라 맵에 저장되는 커넥터를 정의합니다. 이 특성을 작성할 때 커넥터 이름 목록을 전달할 수 있습니다.

consumer-max-rate

소비자 최대 속도(초당).

consumer-window-size

소비자 창 크기(바이트)입니다.

인증 정보 참조

자격 증명 저장소에서 풀링된 연결 팩토리를 인증하기 위한 자격 증명.

deserialization-black-list

역직렬화할 수 없는 클래스 또는 패키지 목록을 정의합니다.

deserialization-white-list

역직렬화할 수 있는 클래스 또는 패키지 목록을 정의합니다.

discovery-group

검색 그룹 이름입니다.

dups-ok-batch-size

dup ok 배치 크기.

enable-amq1-prefix

Jakarta Messaging 대상 이름에 접두사를 포함할지 여부를 지정합니다. 값이 false이면 접두사가 포함되지 않습니다.

enlistment-trace

ironJacamar를 사용하여 이 풀링된 연결 팩토리에 대한 등록 추적을 기록합니다. 이 속성은 기본적으로 정의되지 않으며 ironjacamar.disable_enlistment_trace 시스템 속성으로 구동됩니다.

항목

연결 팩토리를 바인딩해야 하는 JNDI 이름입니다.

failover-on-initial-connection

초기 연결 시 페일오버 여부를 지정합니다.

group-id

그룹 ID입니다.

Ha

연결 팩토리가 고가용성을 지원하는지 여부.

initial-connect-attempts

초기에 이 팩토리와 연결하려는 시도 횟수입니다.

initial-message-packet-size

이 팩토리를 통해 생성된 메시지의 초기 크기입니다.

jndi-params

들어오는 연결의 대상을 찾는 데 사용할 JNDI 매개변수입니다.

managed-connection-pool

이 풀링된 연결 팩토리에서 사용하는 관리되는 연결 풀의 클래스 이름입니다.

max-pool-size

풀의 최대 크기입니다.

max-retry-interval

최대 재시도 간격(밀리초)입니다.

min-large-message-size

최소 큰 메시지 크기(바이트)입니다.

min-pool-size

풀의 최소 크기입니다.

암호

이 연결 팩토리와 함께 사용할 기본 암호입니다. 연결 팩토리가 원격 호스트를 가리키는 경우에만 필요합니다.

pre-acknowledge

미리 파악해야 하는지 여부.

producer-max-rate

생산자 최대 속도(초당).

producer-window-size

생산자 창 크기(바이트)입니다.

protocol-manager-factory

이 풀링된 연결 팩토리에서 사용하는 프로토콜 관리자 팩토리입니다.

reconnect-attempts

재연결 시도. 기본적으로 풀링된 연결 팩토리는 메시징 서버에 무한히 다시 연결을 시도합니다.

retry-interval

재시도 간격(밀리초)입니다.

retry-interval-multiplier

재시도 간격 승수.

scheduled-thread-pool-max-size

예약된 스레드 풀 최대 크기입니다.

setup-attempts

MDB 엔드포인트를 설정하는 횟수입니다.

setup-interval

MDB 엔드포인트를 설정할 때 시도하는 간격(밀리초)입니다.

통계 지원

런타임 통계 활성화 여부.

thread-pool-max-size

스레드 풀 최대 크기입니다.

트랜잭션

트랜잭션 모드입니다.

transaction-batch-size

트랜잭션 배치 크기입니다.

use-auto-recovery

자동 복구 사용 여부.

use-global-pools

글로벌 풀 사용 여부.

use-jndi

JNDI를 사용하여 들어오는 연결의 대상을 찾습니다.

use-local-tx

들어오는 세션에 로컬 트랜잭션을 사용합니다.

use-topology-for-load-balancing

메시징 클라이언트가 클러스터 토폴로지를 사용하여 클러스터에 연결할지 또는 모든 연결에 초기 커넥터를 사용할지 여부를 지정합니다.

user

이 연결 팩토리와 함께 사용할 기본 사용자 이름입니다. 연결 팩토리가 원격 호스트를 가리키는 경우에만 필요합니다.

A.4. Core Bridge 속성
링크 복사

Expand
표 A.4. Core Bridge 속성
속성설명

call-timeout

코어 브리지에서 수행하는 차단 호출에 대한 응답을 기다리는 시간(밀리초)입니다. 중복된 탐지가 구성되지 않은 경우 코어 브리지는 차단 호출을 사용합니다. 기본값은 30000 또는 30초입니다.

check-period

클라이언트 오류 확인 사이의 기간(밀리초)입니다.

confirmation-window-size

메시지를 대상 노드로 전달하는 데 사용되는 연결에 사용할 크기입니다.

connection-ttl

브리지에서 사용하는 연결은 하트비트가 없는 최대 시간(밀리초)으로 간주됩니다.

인증 정보 참조

자격 증명 저장소에서 브리지를 인증하기 위한 자격 증명.

discovery-group

이 브리지에서 사용하는 검색 그룹의 이름입니다. static-connectors 가 정의되면 이 속성을 설정할 수 없습니다.

filter

선택적 필터 문자열입니다. 지정된 경우 지정된 필터 식과 일치하는 메시지만 전달됩니다.

forwarding-address

메시지가 전달될 대상 서버의 주소입니다. 전달 주소를 지정하지 않으면 메시지의 원래 대상이 유지됩니다.

Ha

이 브리지가 고가용성을 지원해야 하는지 여부. true인 경우 클러스터의 사용 가능한 모든 서버에 연결하고 페일오버를 지원합니다. 기본값은 false입니다.

initial-connect-attempts

이 브리지를 사용하여 처음에 연결하려는 시도 횟수입니다.

max-retry-interval

연결을 재시도하는 데 사용되는 최대 시간 간격입니다.

min-large-message-size

큰 메시지로 간주되기 전에 메시지의 최소 크기(바이트)입니다.

암호

원격 서버에 대한 브리지 연결을 만들 때 사용할 암호입니다. 지정하지 않으면 messaging-activemq 하위 시스템 리소스의 cluster-password 특성에서 지정한 기본 클러스터 암호가 사용됩니다.

cluster-credential-reference

클러스터에 인증하는 데 사용되는 인증 정보 저장소 참조입니다. 이는 암호 대신 사용할 수 있습니다.

queue-name

브리지가 사용하는 로컬 대기열의 고유 이름입니다. 시작 시 브리지가 인스턴스화될 때 까지 큐가 이미 존재해야 합니다.

reconnect-attempts

총 재연결 횟수는 종료하고 종료하기 전에 브리지에서 수행할하려고 합니다. 기본값은 -1 로, 시도 횟수를 무제한으로 나타냅니다.

reconnect-attempts-on-same-node

총 재연결 횟수는 브리지에서 종료하고 종료하기 전에 수행할 동일한 노드에서 시도합니다. 값 -1 은 시도 횟수를 나타냅니다. 기본값은 10입니다.

retry-interval

대상 서버에 대한 연결이 실패한 경우 후속 재연결 시도 사이의 기간(밀리초)입니다.

retry-interval-multiplier

마지막 재시도 이후 시간에 적용할 승수로 다음 재시도에 시간을 계산합니다. 이렇게 하면 재시도 시도 간에 지수 백오프를 구현할 수 있습니다.

static-connectors

이 브리지에서 사용하는 정적으로 정의된 커넥터 목록입니다. discovery-group 이 정의된 경우 이 속성을 설정할 수 없습니다.

transformer-class-name

org.apache.activemq.artemis.core.server.cluster.Transformer 인터페이스를 구현하는 사용자 정의 클래스의 이름입니다.

use-duplicate-detection

브리지가 중복된 ID 속성을 전달하는 각 메시지에 자동으로 삽입하는지 여부입니다.

user

원격 서버에 대한 브리지 연결을 만들 때 사용할 사용자 이름입니다. 지정하지 않으면 messaging-activemq 하위 시스템 리소스에서 cluster-user 특성으로 지정한 기본 클러스터 사용자가 사용됩니다.

A.5. 자카르타 메시징 브리지 속성
링크 복사

Expand
표 A.5. 자카르타 메시징 브리지 속성
속성설명

add-messageID-in-header

이 값을 true 로 설정하면 원래 메시지의 메시지 ID가 AMQ_BRIDGE_MSG_ID_LIST 헤더의 대상으로 전송된 메시지에 추가됩니다. 메시지가 두 번 이상 브리지되면 각 메시지 ID가 추가됩니다.

client-id

지속적이고 소스 대상이 주제인 경우 서브스크립션을 만들고 찾을 때 사용할 Jakarta Messaging 클라이언트 ID입니다.

failure-retry-interval

브리지가 실패한 경우 소스 또는 대상 서버에 대한 연결을 재생성할 때까지 대기하는 시간(밀리초)입니다.

max-batch-size

대상 대상으로 배치로 전송하기 전에 소스 대상에서 사용할 최대 메시지 수입니다. 값이 1 이상이어야 합니다.

max-batch-time

사용된 메시지 수가 max-batch-size에 도달하지 않은 경우에도 메시지 배치를 대상으로 보내기 전에 대기할 최대 밀리초 수입니다. 값 -1은 영속적 으로 대기함을 의미합니다.

max-retries

브리지가 실패한 것을 감지하면 소스 또는 대상 서버에 대한 연결을 다시 생성할 횟수입니다. 이 브리지는 이 횟수를 시도한 후 포기합니다. 값 -1 은 영구적으로 시도를 의미합니다.

module

소스 및 대상 Jakarta Messaging 리소스를 조회하는 데 필요한 리소스를 포함하는 JBoss EAP 모듈의 이름입니다.

일시 중지됨

Jakarta Messaging 브리지가 일시 중지되었는지 여부를 보고하는 읽기 전용 속성입니다.

quality-of-service

원하는 서비스 품질 모드. 가능한 값은 AT_MOST_ONCE,DUPLICATES_OK 또는 ONCE_AND_ONLY_ONCE 입니다. 다른 모드에 대한 자세한 내용은 서비스 품질을 참조하십시오.

선택기

소스 대상의 메시지를 사용하는 데 사용되는 자카르타 메시징 선택기 표현식입니다. 선택기 표현식과 일치하는 메시지만 소스에서 대상 대상으로 브리지됩니다.

subscription-name

지속적이고 소스 대상인 경우 서브스크립션의 이름입니다.

Source-connection-factory

소스 메시징 서버에서 조회할 소스 연결 팩토리의 이름입니다.

source-context

소스 JNDI 초기 컨텍스트를 구성하는 데 사용되는 속성입니다.

source-credential-reference

소스 연결을 인증하는 데 사용되는 자격 증명 저장소 참조입니다. 이 방법은 source-password 대신 사용할 수 있습니다.

S2T(Source-destination)

소스 메시징 서버에서 조회할 소스 대상의 이름입니다.

source-password

소스 연결을 생성하는 암호입니다.

source-user

소스 연결을 만드는 사용자의 이름입니다.

target-connection-factory

대상 메시징 서버에서 조회할 대상 연결 팩토리의 이름입니다.

target-context

대상 JNDI 초기 컨텍스트를 구성하는 데 사용되는 속성입니다.

target-credential-reference

대상 연결을 인증하는 데 사용되는 자격 증명 저장소 참조입니다. target-password 대신 사용할 수 있습니다.

target-destination

대상 메시징 서버에서 검색할 대상 대상의 이름입니다.

target-password

대상 연결을 생성하는 암호입니다.

target-user

대상 연결을 만드는 사용자의 이름입니다.

A.6. 클러스터 연결 속성
링크 복사

Expand
표 A.6. 클러스터 연결 속성
속성설명

allow-direct-connections-only

true 로 설정하면 이 노드가 1개 이상의 홉이 있는 경우 클러스터의 다른 노드에 대한 연결을 생성하지 않습니다. static-connectors 속성이 정의된 경우에만 사용됩니다. 기본값은 false입니다.

call-failover-timeout

페일오버가 클러스터 연결에서 수행한 원격 호출에 대한 처리 중일 때 사용할 시간 제한(밀리초)입니다. 기본값은 바인딩되지 않은 -1 입니다.

call-timeout

클러스터 연결에서 수행한 원격 호출에 대한 시간 제한(밀리초)입니다. 기본값은 30000 또는 30초입니다.

check-period

클라이언트 오류 확인 사이의 기간(밀리초)입니다. 기본값은 30000 또는 30초입니다.

cluster-connection-address

각 클러스터 연결은 이 값으로 시작하는 주소에만 전송된 메시지에만 적용됩니다.

confirmation-window-size

메시지를 대상 노드로 전달하는 데 사용되는 연결의 창 크기(바이트)입니다. 기본값은 1048576 입니다.

connection-ttl

클러스터 연결에서 사용하는 연결은 하트비트 없이 활성으로 간주되는 최대 시간(밀리초)입니다. 기본값은 60000 또는 60초입니다.

connector-name

클러스터 연결에 사용할 커넥터의 이름입니다.

discovery-group

이 클러스터 연결이 연결될 클러스터의 다른 서버 목록을 가져오는 데 사용되는 검색 그룹입니다. static-connectors 가 정의된 경우 정의되지 않은(null)이어야 합니다.

initial-connect-attempts

이 클러스터 연결 초기에 연결 시도 횟수입니다. 기본값은 바인딩되지 않은 -1 입니다.

max-hops

메시지를 전달할 수 있는 최대 횟수입니다. JBoss EAP는 체인의 중간체로 다른 ActiveMQ Artemis 메시징 서버와 간접적으로 연결된 노드에 메시지의 부하를 분산하도록 구성할 수도 있습니다. 기본값은 1입니다.

max-retry-interval

연결을 재시도하는 데 사용되는 최대 시간 간격(밀리초)입니다. 기본값은 2000 또는 2초입니다.

message-load-balancing-type

이 매개 변수는 클러스터의 다른 노드 간에 메시지를 분산하는 방법을 결정합니다. 더 이상 사용되지 않는 forward-when-no-consumers를 대체합니다. 유효한 값은 OFF,STRICT 또는 ON_DEMAND 입니다.

꺼짐
메시지는 클러스터의 다른 노드로 전달되지 않습니다.
STRICT
클러스터의 다른 노드에 있는 동일한 큐에 소비자가 전혀 없거나 일치하지 않는 메시지 필터 또는 선택기가 없는 소비자가 있더라도 메시지는 라운드 로빈 방식으로 배포됩니다. 이 매개 변수가 STRICT 으로 설정되어 있어도 다른 노드에 동일한 이름의 대기열이 없는 경우 JBoss EAP는 다른 노드로 메시지를 전달하지 않습니다. STRICT 사용은 레거시 forward-when-no-consumers 매개변수를 true 로 설정하는 것과 같습니다.
ON_DEMAND
전달 주소에 소비자가 있는 큐가 있는 경우 메시지는 클러스터의 다른 노드로 전달됩니다. 해당 소비자에 메시지 필터 또는 선택기가 있는 경우 해당 선택기 중 하나 이상이 메시지와 일치해야 합니다. ON_DEMAND 사용은 레거시 forward-when-no-consumers 매개 변수를 false로 설정하는 것과 같습니다.

기본값은 ON_DEMAND 입니다.

min-large-message-size

큰 메시지로 간주되기 전에 메시지의 최소 크기(바이트)입니다. 기본값은 102400 입니다.

node-id

이 클러스터 연결에서 사용하는 노드 ID입니다. 이 속성은 읽기 전용입니다.

notification-attempts

클러스터 연결 자체를 브로드캐스트할 횟수. 기본값은 2 입니다.

notification-interval

알림 간 간격(밀리초)입니다. 기본값은 10000 또는 10초입니다.

reconnect-attempts

총 재연결 횟수가 브리지를 종료하고 종료하기 전에 수행하는 횟수입니다. 기본값은 -1 로, 시도 횟수를 무제한으로 나타냅니다.

retry-interval

대상 서버에 대한 연결이 실패한 경우 후속 서버에서 다시 연결을 시도하는 기간(밀리초)입니다. 기본값은 500 입니다.

retry-interval-multiplier

마지막 재시도 이후 시간에 적용할 승수로 다음 재시도에 시간을 계산합니다. 이렇게 하면 재시도 시도 간에 지수 백오프를 구현할 수 있습니다. 기본값은 1.0 입니다.

static-connectors

이 클러스터 연결이 연결을 만드는 정적으로 정의된 커넥터 목록입니다. discovery-group-name 이 정의된 경우 정의되지 않아야 합니다.

토폴로지

이 클러스터 연결이 인식하는 노드의 토폴로지입니다. 이 속성은 읽기 전용입니다.

use-duplicate-detection

브리지가 중복된 ID 속성을 전달하는 각 메시지에 자동으로 삽입하는지 여부입니다. 기본값은 true입니다.

A.7. 메시징 통계
링크 복사

대기열 통계
Expand
표 A.7. 대기열 통계
통계설명

소비자 개수

이 큐의 메시지를 사용하는 소비자 수입니다.

메시지 개수

이 큐에 현재 있는 메시지 수입니다.

추가된 메시지 개수

생성된 이후 이 큐에 추가된 메시지 수입니다.

예약된 개수

이 큐에서 예약된 메시지 수입니다.

주제 통계
Expand
표 A.8. 주제 통계
통계설명

개수 전달

이 주제에서 현재 소비자에게 전달하는 메시지 수입니다.

지속적 메시지 수

이 항목의 모든 지속적 구독자에 대한 메시지 수입니다.

지속적 서브스크립션 수

이 항목의 지속적 서브스크립션 가입 수.

메시지 개수

이 주제의 현재 메시지 수입니다.

추가된 메시지

이 항목에 추가된 메시지 수입니다.

서브스크립션 수

이 주제에 대한 지속적 및 비내구성 가입자 수.

풀링된 연결 팩토리 통계
참고

풀링된 연결 팩토리의 통계 컬렉션은 메시징 서버에 대해 수집된 다른 통계와 별도로 활성화됩니다. 다음 관리 CLI 명령을 사용하여 풀링된 연결 팩토리에 대한 통계 컬렉션을 활성화합니다. 

/subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=statistics-enabled,value=true)
Copy to Clipboard Toggle word wrap
Expand
표 A.9. 풀링된 연결 팩토리 통계
통계설명

ActiveCount

활성 개수.

AvailableCount

사용 가능한 개수.

AverageBlockingTime

평균 풀 차단 시간.

AverageCreationTime

실제 연결을 생성하는 데 사용된 평균 시간입니다.

AverageGetTime

실제 연결을 가져오는 데 사용된 평균 시간입니다.

AveragePoolTime

풀의 물리적 연결에서 사용된 평균 시간입니다.

AverageUsageTime

실제 연결을 사용하는 데 사용된 평균 시간입니다.

BlockingFailureCount

물리적 연결을 얻기 위해 시도하는 실패 수입니다.

CreatedCount

생성된 개수입니다.

DestroyedCount

삭제된 개수.

IdleCount

현재 유휴 상태의 실제 연결 수입니다.

InUseCount

현재 사용 중인 물리적 연결 수입니다.

MaxCreationTime

물리적 연결을 만드는 최대 시간.

MaxGetTime

물리적 연결을 얻기 위한 최대 시간.

MaxPoolTime

풀에서 물리적 연결의 최대 시간.

MaxUsageTime

물리적 연결을 사용하는 최대 시간.

MaxUsedCount

사용된 최대 연결 수입니다.

MaxWaitCount

연결 대기 중인 최대 스레드 수입니다.

MaxWaitTime

연결을 위한 최대 대기 시간입니다.

TimedOut

시간 초과된 개수.

TotalBlockingTime

총 차단 시간.

TotalCreationTime

물리적 연결을 만드는 데 사용된 총 시간입니다.

TotalGetTime

물리적 연결을 가져오는 데 사용된 총 시간입니다.

TotalPoolTime

풀에서 물리적 연결에 사용된 총 시간.

TotalUsageTime

물리적 연결을 사용하여 사용된 총 시간입니다.

WaitCount

물리적 연결을 얻기 위해 기다려야 하는 요청 수입니다.

XACommitAverageTime

XAResource 커밋 호출의 평균 시간입니다.

XACommitCount

XAResource 커밋 호출 수입니다.

XACommitMaxTime

XAResource 커밋 호출의 최대 시간입니다.

XACommitTotalTime

모든 XAResource 커밋 호출의 총 시간입니다.

XAEndAverageTime

XAResource 종료 호출의 평균 시간입니다.

XAEndCount

XAResource 종료 호출 수입니다.

XAEndMaxTime

XAResource 종료 호출의 최대 시간입니다.

XAEndTotalTime

모든 XAResource 종료 호출의 총 시간입니다.

XAForgetAverageTime

평균 XAResource의 시간은 호출을 잊습니다.

XAForgetCount

XAResource 수는 호출을 잊습니다.

XAForgetMaxTime

XAResource의 최대 시간은 호출을 잊습니다.

XAForgetTotalTime

모든 XAResource의 총 시간은 호출을 잊습니다.

XAPrepareAverageTime

XAResource 준비 호출의 평균 시간입니다.

XAPrepareCount

XAResource prepare 호출 수입니다.

XAPrepareMaxTime

XAResource prepare 호출의 최대 시간입니다.

XAPrepareTotalTime

모든 XAResource 준비 호출의 총 시간입니다.

XARecoverAverageTime

XAResource 복구 호출의 평균 시간입니다.

XARecoverCount

XAResource 복구 호출 수입니다.

XARecoverMaxTime

XAResource 복구 호출의 최대 시간입니다.

XARecoverTotalTime

모든 XAResource의 총 시간은 호출을 복구합니다.

XARollbackAverageTime

XAResource 롤백 호출의 평균 시간입니다.

XARollbackCount

XAResource 롤백 호출 수입니다.

XARollbackMaxTime

XAResource 롤백 호출의 최대 시간입니다.

XARollbackTotalTime

모든 XAResource 롤백 호출의 총 시간입니다.

XAStartAverageTime

XAResource 시작 호출의 평균 시간입니다.

XAStartCount

XAResource 시작 호출 수입니다.

XAStartMaxTime

XAResource start 호출의 최대 시간입니다.

XAStartTotalTime

모든 XAResource start 호출의 총 시간입니다.





2024-02-08에 최종 업데이트된 문서

법적 공지
링크 복사

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat