Message Queue 4.0에는 다음과 같은 새로운 기능이 추가되었습니다.
이러한 기능에 대해서는 이어지는 절에서 설명합니다.
버전 4.0에 도입된, 작지만 잠재적으로 혁신적인 변경 사항 중 하나는 비밀번호를 지정하는 명령줄 옵션이 폐지되었다는 점입니다. 이제부터는 더 이상 사용되지 않는 비밀번호 옵션의 설명대로 한 파일에 모든 비밀번호를 저장해야 합니다.
Message Queue 버전 4.0에는 사용 불능 메시지 대기열에 있던 모든 메시지에 설정할 수 있는 등록 정보 두 가지가 새롭게 추가되었습니다.
JMS_SUN_DMQ_PRODUCING_BROKER는 메시지를 생성한 브로커를 나타냅니다.
JMS_SUN_DMQ_DEAD_BROKER는 메시지를 사용 불능으로 표시한 브로커를 나타냅니다.
Message Queue 버전 4.0에는 사용 불능 메시지 대기열에 있던 모든 메시지에 설정할 수 있는 등록 정보 두 가지가 새롭게 추가되었습니다.
JMS_SUN_DMQ_PRODUCING_BROKER는 메시지를 생성한 브로커를 나타냅니다.
JMS_SUN_DMQ_DEAD_BROKER는 메시지를 사용 불능으로 표시한 브로커를 나타냅니다.
imqdbmgr 명령에 query 하위 명령이 추가되었습니다. 저장소 버전, 데이터베이스 사용자 및 데이터베이스 테이블이 만들어졌는지의 여부를 포함한 영구 저장소에 대한 정보를 표시하려면 이 하위 명령을 사용합니다.
다음은 이 명령을 사용하여 표시한 정보의 예를 나타냅니다.
imqdbmgr query |
[04/Oct/2005:15:30:20 PDT] Using plugged-in persistent store: version=400 brokerid=Mozart1756 database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb database user=scott Running in standalone mode. Database tables have already been created. |
Message Queue 버전 3.7 UR1에는 성능을 향상시킬 수 있는, 영구 저장소 형식에 대한 두 가지 변경 사항이 도입되었습니다. 하나는 파일 저장소에 대한 변경 사항이며 다른 하나는 JDBC 저장소에 대한 변경 사항입니다.
파일 저장소에 저장되는 트랜잭션 데이터의 형식
Message Queue의 파일 기반 영구 저장소에 저장되는 트랜잭션 상태 정보 형식이 변경되어 디스크 입출력이 줄었으며 JMS 트랜잭션의 성능이 향상되었습니다.
Oracle JDBC 저장소
이전 버전의 Message Queue에서 Oracle용 저장소 스키마는 LONG RAW 데이터 유형을 사용하여 메시지 데이터를 저장했습니다. Oracle 8에서는 BLOB 데이터 유형을 도입했으며 LONG RAW 유형은 더 이상 사용하지 않습니다. Message Queue 3.7 UR1에서는 성능 및 지원 가능성 향상을 위해 BLOB 데이터 유형으로 전환했습니다.
이러한 변경 사항은 저장소 호환성에 영향을 주기 때문에 Message Queue 버전 3.7 UR1에서 파일 저장소 및 JDBC 저장소의 버전이 모두 350에서 370으로 변경되었습니다.
Message Queue 버전 4.0에서는 JDBC 저장소를 최적화하고 향후 향상된 기능을 지원할 수 있는 변경 내용이 도입되었습니다. 이러한 이유로 JDBC 저장소 버전이 400으로 업그레이드되었습니다. 버전 4.0에서는 파일 기반의 영구 저장소 버전이 변경되지 않고 370으로 유지됩니다.
Message Queue 4.0은 파일 기반 영구 저장소 및 JDBC 영구 저장소를 최신 버전으로 자동으로 변환할 수 있도록 지원합니다. 처음 imqbrokerd가 시작될 때 유틸리티에서 이전 저장소를 감지하면 이전 저장소를 그대로 두고 새 형식의 저장소로 마이그레이션합니다.
파일 기반의 저장소 버전 200 및 350은 370 버전 형식으로 마이그레이션됩니다.
JDBC 저장소 버전 350 및 370은 400 버전 형식으로 마이그레이션됩니다. (200 저장소를 업그레이드해야 하는 경우에는 먼저 중간에 있는 3.5 또는 3.6 릴리스 단계를 밟아야 합니다.)
이 업그레이드를 롤백해야 하는 경우 Message Queue 4.0 설치를 제거한 다음 이전에 실행 중이던 버전을 다시 설치할 수 있습니다. 이전 저장소의 복사본이 그대로 유지되므로 브로커는 이전 저장소 복사본을 실행할 수 있습니다.
관리자가 브로커를 정지하거나, 지정된 간격 후 브로커를 종료하거나, 연결을 삭제하거나, java 시스템 등록 정보(예: 연결 관련 등록 정보)를 설정할 수 있도록 해주는 하위 명령 및 여러 옵션이 명령 유틸리티(imqcmd)에 받습니다.)
브로커를 정지하면 브로커가 자동 상태가 되며 브로커가 종료되거나 다시 시작되기 전에 메시지가 드레인됩니다. 정지된 브로커에는 새 연결을 만들 수 없습니다. 브로커를 정지하려면 다음 명령을 입력하십시오.
imqcmd quiesce bkr -b Wolfgang:1756
지정된 간격 후 브로커를 종료하려면 다음 명령을 입력하십시오. (시간 간격은 브로커가 종료되기 전에 대기하는 시간(초)을 지정합니다.)
imqcmd shutdown bkr -b Hastings:1066 -time 90
시간 간격을 지정하면 브로커에서 종료 시간을 나타내는 메시지를 기록합니다. 예를 들면 다음과 같습니다.
Shutting down the broker in 29 seconds (29996 milliseconds)
브로커 종료 대기 중 해당 동작은 다음과 같은 방식으로 영향을 받습니다.
관리 jms 연결은 계속 허용됩니다.
새 jms 연결은 허용되지 않습니다.
기존 jms 연결은 계속 작동합니다.
브로커는 고가용성 클러스터 내의 다른 브로커를 인계 받을 수 없습니다.
imqcmd 유틸리티는 차단되지 않고 종료 요청을 브로커에 전송하며 즉시 반환됩니다.
연결을 삭제하려면 다음 명령을 입력하십시오.
imqcmd destroy cxn -n 2691475382197166336
연결 아이디를 가져오려면 imqcmd list cxn 또는 imqcmd query cxn 명령을 사용합니다.
imqcmd를 사용하여 시스템 등록 정보를 설정하려면 새로운 –D 옵션을 사용하십시오. 이 명령은 JMS 연결 팩토리 등록 정보 또는 연결 관련 java 시스템 등록 정보를 설정하거나 대체할 때 유용합니다. 예를 들면 다음과 같습니다.
imqcmd list svc -secure -DimqSSLIsHostTrusted=true imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore -Djavax.net.ssl.trustStorePassword=mytrustword
imqcmd 명령의 구문에 대한 자세한 내용은 Sun Java System Message Queue 4.1 Administration Guide의 13 장, Command Line Reference를 참조하십시오.
이제 Apache Derby 버전 10.1.1이 JDBC 호환 영구 저장소 공급자로 지원됩니다.
릴리스 4.0 시작 시 클라이언트 연결 팩토리 등록 정보 imqSSLIsHostTrusted의 기본값은 false입니다. 응용 프로그램이 이전 기본값 true를 따르는 경우에는 등록 정보를 재구성하여 명시적으로 true로 설정해야 합니다.
자체 서명된 인증서를 사용하도록 브로커를 구성한 경우 호스트를 신뢰하도록 선택할 수 있습니다. 이 경우 imqConnectionType 등록 정보를 사용하여 연결이 SSL 기반 연결 서비스를 사용하도록 지정해야 할 뿐 아니라 imqSSLIsHostTrusted 등록 정보를 true로 설정해야 합니다.
예를 들어, 브로커가 자체 서명된 인증서를 사용할 때 클라이언트 응용 프로그램을 안전하게 실행하려면 다음 명령을 사용합니다.
java -DimqConnectionType=TLS -DimqSSLIsHostTrusted=true <ClientAppName>
브로커가 자체 서명된 인증서를 사용할 때 관리 도구 imqcmd를 안전하게 실행하려면 다음 명령을 사용합니다.
imqcmd list svc -secure -DimqSSLIsHostTrusted=true
JMX(Java Management Extensions) 사양에 따라 Message Queue 브로커 구성 및 모니터링을 위한 새로운 API가 추가되었습니다. 이 API를 사용하여 Message Queue 클라이언트 응용 프로그램 내에서 브로커 기능을 프로그래밍 방식으로 구성하고 모니터링할 수 있습니다. 이전 버전의 Message Queue에서는 명령줄이나 관리 콘솔을 통해서만 이 기능에 액세스할 수 있었습니다.
API는 다음 Message Queue 관련 자원을 관리하기 위한 JMX Managed Beans(MBeans) 집합으로 구성됩니다.
메시지 브로커
연결 서비스
연결
대상
메시지 생성자
메시지 사용자
트랜잭션
브로커 클러스터
로깅
JVM(Java Virtual Machine)
이 MBean은 상태 변경 사항이 발생할 때 클라이언트 응용 프로그램이 이 변경 사항을 수신하고 이에 대해 비동기식으로 응답할 수 있도록 해주는 알림뿐 아니라 기본 자원의 상태를 동기식으로 폴링하고 조작하는 데 필요한 속성 및 작업을 제공합니다. 클라이언트 응용 프로그램은 JMX API를 사용하여 다음과 같은 구성 및 모니터링 작업을 수행할 수 있습니다.
브로커의 포트 번호 설정
브로커의 최대 메시지 크기 설정
연결 서비스 일시 중지
연결 서비스에 대한 최대 스레드 수 설정
서비스에서 현재 연결 수 가져오기
연결 삭제
대상 만들기
대상 삭제
대상 자동 만들기 활성화 또는 비활성화
대상에서 모든 메시지 제거
브로커가 시작된 후 대상에서 수신한 누적 메시지 수 가져오기
대기열의 현재 상태(실행 중 또는 일시 중지됨) 가져오기
주제에 대한 현재 메시지 생성자 수 가져오기
영구 가입자의 모든 메시지 제거
현재 JVM 힙 크기 가져오기
JMX API에 대한 소개와 전체 참조 정보에 대해서는 Sun Java System Message Queue 4.1 Developer’s Guide for JMX Clients를 참조하십시오.
JMX API를 지원하기 위한 몇 개의 새로운 브로커 등록 정보가 추가되었습니다(표 1–3 참조). 이 등록 정보는 명령줄에서 Message Queue 명령 유틸리티(imqcmd)를 사용하여 설정할 수 없습니다. 대신, 브로커 유틸리티(imqbrokerd)의 -D 옵션을 사용하여 설정하거나 브로커의 인스턴스 구성 파일(config.properties)에서 직접 편집할 수 있습니다. 또한 이러한 등록 정보의 일부(imq.jmx.rmiregistry.start, imq.jmx.rmiregistry.use, imq.jmx.rmiregistry.port)는 표 1–4에서 설명하는 새로운 브로커 유틸리티 옵션을 사용하여 설정할 수 있습니다. 다음 표에서는 각 옵션을 나열하고 해당 유형 및 용도를 지정 및 설명합니다.
표 1–3 JMX 지원을 위한 새 브로커 등록 정보
imq.jmx.connector.list 등록 정보는 브로커 시작 시 명명된 JMX 커넥터 집합을 만들도록 정의합니다. imq.jmx.connector.activelist는 만들어진 커넥터 집합에서 활성화할 커넥터를 지정합니다. 명명된 각 커넥터에는 다음과 같은 고유 등록 정보 집합이 있습니다.
imq.jmx.connector.connectorName .urlpath |
imq.jmx.connector.connectorName .useSSL |
imq.jmx.connector.connectorName .brokerHostTrusted |
기본적으로 jmxrmi와 ssljmxrmi라고 하는 두 가지 JMX 커넥터가 만들어집니다. 첫 번째 커넥터는 SSL 암호화를 사용하지 않도록 구성되며(imq.jmx.connector.jmxrmi.useSSL = false), 두 번째 커넥터는 이 암호화를 사용하도록 구성됩니다(imq.jmx.connector.ssljmxrmi.useSSL = true). 기본적으로 브로커 시작 시 jmxrmi 커넥터만 활성화됩니다. 보안 통신을 위해 ssljmxrmi 커넥터를 활성화하는 방법에 대한 내용은 JMX 클라이언트에 대한 SSL 지원을 참조하십시오.
편의상 새 옵션(표 1–4)도 RMI 레지스트리에 대한 사용, 시작 및 포트를 제어하기 위해 명령줄 브로커 유틸리티(imqbrokerd)에 추가되었습니다. 이러한 옵션의 사용과 효과는 표 1–3에서 설명하는 것처럼 해당 브로커 등록 정보와 동일합니다. 다음 표에서는 각 옵션을 나열하고 해당 브로커 등록 정보 및 용도를 지정 및 설명합니다.
표 1–4 JMX 지원을 위한 새 브로커 유틸리티 옵션
옵션 |
해당 브로커 등록 정보 |
설명 |
---|---|---|
-startRmiRegistry |
imq.jmx.rmiregistry.start |
브로커 시작 시 RMI 레지스트리를 시작할지 여부를 지정합니다. |
-useRmiRegistry |
imq.jmx.rmiregistry.use |
외부 RMI 레지스트리를 사용할지 여부를 지정합니다. |
-rmiRegistryPort |
imq.jmx.rmiregistry.port |
RMI 레지스트리의 포트 번호입니다. |
브로커 시작 시 작성 및 시작되는 JMX 커넥터의 JMX 서비스 URL을 나열하기 위한 새로운 하위 명령(표 1–5)이 명령줄 명령 유틸리티(imqcmd)에 추가되었습니다. 이 정보는 JMX 커넥터를 가져오는 데 Message Queue 편의 클래스 AdminConnectionFactory를 사용하지 않는 JMX 클라이언트에 필요하며, Java 모니터링 및 관리 콘솔(jconsole)과 같은 일반 JMX 브라우저를 통해 Message Queue를 관리하거나 모니터링하는 데 사용할 수도 있습니다.
표 1–5 새 명령 유틸리티 하위 명령
하위 명령 |
설명 |
---|---|
list jmx |
JMX 커넥터의 JMX 서비스 URL을 나열합니다. |
위에 언급한 바와 같이 Message Queue 메시지 브로커는 기본적으로 사전 구성된 JMX 커넥터 jmxrmi를 사용하므로 보안 통신이 설정되지 않은 상태로 구성됩니다. 응용 프로그램에 보안 통신을 위한 SSL(Secure Socket Layer)을 사용하려면 대신 사용할 수 있는 보안 JMX 커넥터 ssljmxrmi를 활성화해야 합니다. 이 커넥터를 활성화하려면 다음 단계를 수행해야 합니다.
Message Queue 관리 설명서에 설명된 대로 ssljms, ssladmin 또는 cluster 연결 서비스와 동일한 방법으로 서명된 인증서를 가져오고 설치합니다.
필요 시 트러스트 저장소에 루트 인증 기관 인증서를 설치합니다.
브로커 시작 시 활성화될 수 있도록 다음과 같이 JMX 커넥터 목록에 ssljmxrmi 커넥터를 추가합니다.
imq.jmx.connector.activelist=jmxrmi,ssljmxrmi
Message Queue 브로커 유틸리티(imqbrokerd)에 비밀번호 파일의 키 저장소 비밀번호를 전달하거나 프롬프트 창의 명령줄에서 이 유틸리티를 입력하여 브로커를 시작합니다.
기본적으로 ssljmxrmi 커넥터(또는 다른 SSL 기반 커넥터)는 제공되는 모든 브로커 SSL 인증서를 검증하도록 구성됩니다. 이 검증을 수행하지 않으려면(예를 들어, 소프트웨어 테스트 중 자체 서명된 인증서를 사용할 경우) 브로커 등록 정보 imq.jmx.connector.ssljmxrmi.brokerHostTrusted를 true로 설정합니다.
클라이언트 측에서는 다음과 같이 ssljmxrmi를 기본 커넥터로 지정하는 URL로 관리자 연결 팩토리(AdminConnectionFactory)를 구성해야 합니다.
AdminConnectionFactory acf = new AdminConnectionFactory(); acf.setProperty(AdminConnectionConfiguration.imqAddress, "mq://myhost:7676/ssljmxrmi");
필요 시 시스템 등록 정보 javax.net.ssl.trustStore 및 javax.net.ssl.trustStorePassword를 사용하여 JMX 클라이언트가 트러스트 저장소를 가리키도록 설정합니다.
이 절에서는 Message Queue 4.0의 연결 및 세션 관련 이벤트에 대한 클라이언트 런타임 로깅 지원에 대해 설명합니다.
JDK 1.4 이상 버전에는 java.util.logging 라이브러리가 포함되어 있습니다. 이 라이브러리는 응용 프로그램 특정 로깅에 사용할 수 있는 표준 로거 인터페이스를 구현합니다.
Message Queue 클라이언트 런타임은 Java 로깅 API를 사용하여 로깅 기능을 구현합니다. 모든 J2SE 1.4 로깅 기능을 사용하여 로깅 작업을 구성할 수 있습니다. 예를 들어, 응용 프로그램은 다음과 같은 Java 로깅 기능을 사용하여 Message Queue 클라이언트 런타임이 해당 로깅 정보를 출력하는 방법을 구성할 수 있습니다.
로깅 처리기
로깅 필터
로깅 포매터
로깅 수준
Java 로깅 API에 대한 자세한 내용은 http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html의 Java Logging Overview를 참조하십시오.
Message Queue 공급자는 로깅 구성을 적절하게 설정한 경우 Message Queue 클라이언트가 연결 및 세션 이벤트를 기록할 수 있도록 해주는 로깅 수준 및 로깅 작업과 연관된 로깅 이름 공간 집합을 정의합니다.
Message Queue 클라이언트 런타임의 루트 로깅 이름 공간은 javax.jms로 정의됩니다. Message Queue 클라이언트 런타임의 모든 로거에서 이 이름을 부모 이름 공간으로 사용합니다.
Message Queue 클라이언트 런타임에 사용되는 로깅 수준은 java.util.logging.Level 클래스에 정의된 로깅 수준과 동일합니다. 이 클래스는 7개의 표준 로그 수준과 로깅 기능을 활성화 및 비활성화하는 데 사용할 수 있는 2가지 추가 설정을 정의합니다.
로깅을 비활성화합니다.
최고 우선 순위로 가장 높은 값입니다. 응용 프로그램에서 정의됩니다.
응용 프로그램에서 정의됩니다.
응용 프로그램에서 정의됩니다.
응용 프로그램에서 정의됩니다.
응용 프로그램에서 정의됩니다.
응용 프로그램에서 정의됩니다.
최저 우선 순위로 가장 낮은 값입니다. 응용 프로그램에서 정의됩니다.
모든 메시지 로깅을 활성화합니다.
일반적으로 Message Queue 클라이언트 런타임에서 발생한 예외 및 오류는 이름 공간이 javax.jms인 로거에서 기록합니다.
JVM에서 발생하여 클라이언트 런타임이 수신하는 예외(예: IOException)는 로깅 이름 공간이 javax.jms인 로거가 WARNING 수준에서 기록합니다.
클라이언트 런타임에서 발생하는 JMS 예외(예: IllegalStateException)는 로깅 이름 공간이 javax.jms인 로거가 FINER 수준에서 기록합니다.
JVM에서 발생하여 클라이언트 런타임이 수신하는 오류(예: OutOfMemoryError)는 로깅 이름 공간이 javax.jms인 로거가 SEVERE 수준에서 기록합니다.
다음에 나오는 표에는 JMS 연결 및 세션에 대한 이벤트를 기록하기 위해 설정해야 하는 로그 수준과 기록할 수 있는 이벤트가 나열되어 있습니다.
다음 표에서는 연결에 대한 로그 수준과 이벤트에 대해 설명합니다.
표 1–6 javax.jms.connection 이름 공간에 대한 로그 수준 및 이벤트
로그 수준 |
이벤트 |
---|---|
FINE |
연결 생성 |
FINE |
연결 시작 |
FINE |
연결 닫힘 |
FINE |
연결 끊어짐 |
FINE |
다시 연결됨 |
FINER |
setClientID와 같은 기타 연결 작업 |
FINEST |
메시지, 확인, Message Queue 작업 및 제어 메시지(예: 트랜잭션 완결) |
세션의 경우에는 다음 정보가 로그 레코드에 기록됩니다.
사용자에 전송된 메시지에 대한 각 로그 레코드에는 ConnectionID, SessionID 및 ConsumerID가 포함됩니다.
생성자에서 전송한 메시지에 대한 각 로그 레코드에는 ConnectionID, SessionID, ProducerID 및 대상 이름이 포함됩니다.
다음 표에서는 세션에 대한 로그 수준과 이벤트에 대해 설명합니다.
표 1–7 javax.jms.session 이름 공간에 대한 로그 수준 및 이벤트
로그 수준 |
이벤트 |
---|---|
FINE |
세션 생성 |
FINE |
세션 닫힘 |
FINE |
생성자 생성 |
FINE |
사용자 생성 |
FINE |
대상 생성 |
FINER |
세션 완결과 같은 기타 세션 작업 |
FINEST |
메시지 생성 및 사용(메시지 등록 정보 및 본문은 로그 레코드에 기록되지 받습니다.) |
기본적으로 출력 로그 수준은 응용 프로그램이 실행 중인 JRE에서 상속됩니다. 해당 수준을 확인하려면 JRE_DIRECTORY/lib/logging.properties 파일을 확인하십시오.
프로그래밍 방식이나 구성 파일을 사용하여 로깅을 구성할 수 있고 로깅의 범위를 제어할 수 있습니다. 다음 절에서는 이러한 작업에 대해 설명합니다.
다음 예는 Java 런타임 환경의 로그 수준을 설정하는 데 사용되는 JRE_DIRECTORY/lib/logging.properties 파일에 로깅 이름 공간 및 수준을 설정하는 방법을 나타냅니다. 이 JRE를 사용하는 모든 응용 프로그램에는 동일한 로깅 구성이 있습니다. 다음의 예제 구성은 javax.jms.connection 이름 공간에 대해 로깅 수준을 INFO로 설정하며 출력을 java.util.logging.ConsoleHandler에 기록할 것을 지정합니다.
#logging.properties file. # "handlers" specifies a comma separated list of log Handler # classes. These handlers will be installed during VM startup. # Note that these classes must be on the system classpath. # By default we only configure a ConsoleHandler, which will only # show messages at the INFO and above levels. handlers= java.util.logging.ConsoleHandler # Default global logging level. # This specifies which kinds of events are logged across # all loggers. For any given facility this global level # can be overriden by a facility-specific level. # Note that the ConsoleHandler also has a separate level # setting to limit messages printed to the console. .level= INFO # Limit the messages that are printed on the console to INFO and above. java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter # The logger with javax.jms.connection name space will write # Level.INFO messages to its output handler(s). In this configuration # the ouput handler is set to java.util.logging.ConsoleHandler. javax.jms.connection.level = INFO
응용 프로그램을 실행하는 데 사용하는 java 명령줄에서 로깅 구성 파일을 정의할 수도 있습니다. 응용 프로그램은 지정한 로깅 파일에 정의된 구성을 사용합니다. 다음 예에서 configFile은 JRE_DIRECTORY/lib/logging.properties 파일에 정의된 형식과 동일한 형식을 사용합니다.
java -Djava.util.logging.config.file=configFile MQApplication
java.util.logging API를 사용하는 다음 코드는 javax.jms.connection 이름 공간 로그 수준을 FINE으로 변경하여 연결 이벤트를 기록합니다. 이러한 코드를 응용 프로그램에 포함시킴으로써 프로그래밍 방식으로 로깅 구성을 설정할 수 있습니다.
import java.util.logging.*; //construct a file handler and output to the mq.log file //in the system's temp directory. Handler fh = new FileHandler("%t/mq.log"); fh.setLevel (Level.FINE); //Get Logger for "javax.jms.connection" domain. Logger logger = Logger.getLogger("javax.jms.connection"); logger.addHandler (fh); //javax.jms.connection logger would log activities //with level FINE and above. logger.setLevel (Level.FINE);
Message Queue 클라이언트는 연결 이벤트 알림을 통해 닫힘 및 다시 연결 이벤트를 수신하고 알림 유형 및 연결 상태를 기반으로 적절한 작업을 수행할 수 있습니다. 예를 들어, 페일오버가 발생하고 클라이언트가 다른 브로커에 다시 연결된 경우 응용 프로그램은 해당 트랜잭션 상태를 정리하고 새 트랜잭션으로 작업을 계속하려 할 수 있습니다.
Message Queue 공급자가 연결에서 심각한 문제를 감지한 경우에는 연결 객체의 등록된 예외 수신기를 호출한 후 이 수신기의 onException 메소드를 호출하고, 문제를 설명하는 JMSException 인수를 이 메소드에 전달합니다. 또한 Message Queue 공급자는 클라이언트 런타임이 연결 상태 변경 사항을 응용 프로그램에 알릴 수 있도록 해주는 이벤트 알림 API를 제공하기도 합니다. 알림 API는 다음 요소로 정의됩니다.
이벤트 수신기 및 알림 이벤트 객체를 정의하는 com.sun.messaging.jms.notification 패키지
javax.jms.Connection 인터페이스에 대한 확장을 정의하는 com.sun.messaging.jms.Connection 인터페이스
다음 절에서는 알림을 트리거할 수 있는 이벤트에 대한 정보와 이벤트 수신기를 만들 수 있는 방법에 대해 설명합니다.
다음 표에서는 이벤트 수신기에서 반환할 수 있는 이벤트를 나열하고 설명합니다.
연결 이벤트가 발생한 경우에는 JMS 예외 수신기가 호출되지 않습니다. 이 예외 수신기는 클라이언트 런타임이 다시 연결 시도를 모두 소진한 경우에만 호출됩니다. 클라이언트 런타임은 항상 예외 수신기보다 이벤트 수신기를 먼저 호출합니다.
표 1–8 알림 이벤트
이벤트 유형 |
의미 |
---|---|
ConnectionClosingEvent |
Message Queue 클라이언트 런타임이 관리자의 종료 요청으로 인해 연결이 닫히려고 하는 브로커에서 알림을 수신한 경우 이 이벤트를 생성합니다. |
ConnectionClosedEvent |
브로커 오류나 관리자의 종료 또는 다시 시작 요청으로 인해 연결이 닫힌 경우 Message Queue 클라이언트 런타임이 이 이벤트를 생성합니다. 이벤트 수신기가 ConnectionClosedEvent를 수신한 경우 응용 프로그램은 수신된 이벤트의 getEventCode() 메소드를 사용하여 연결이 닫힌 원인을 지정하는 이벤트 코드를 가져올 수 있습니다. |
ConnectionReconnectedEvent |
Message Queue 클라이언트 런타임이 브로커에 다시 연결되었음을 나타냅니다. 이는 이전에 클라이언트에 연결되었던 동일한 브로커이거나 다른 브로커일 수 있습니다. 응용 프로그램은 수신된 이벤트의 getBrokerAddress 메소드를 사용하여 다시 연결된 브로커의 주소를 가져올 수 있습니다. |
ConnectionReconnectFailedEvent |
Message Queue 클라이언트 런타임을 브로커에 다시 연결하지 못했음을 나타냅니다. 다시 연결 시도에 실패할 때마다 런타임은 새 이벤트를 생성하고 이를 이벤트 수신기에 전송합니다. 연결 이벤트가 발생한 경우에는 JMS 예외 수신기가 호출되지 않습니다. 이 예외 수신기는 클라이언트 런타임이 다시 연결 시도를 모두 소진한 경우에만 호출됩니다. 클라이언트 런타임은 항상 예외 수신기보다 이벤트 수신기를 먼저 호출합니다. |
다음 코드 예는 연결 이벤트 수신기를 설정하는 방법을 나타냅니다. 연결 이벤트가 발생할 때마다 클라이언트 런타임에 의해 이벤트 수신기의 onEvent 메소드가 호출됩니다.
//create an MQ connection factory. com.sun.messaging.ConnectionFactory factory = new com.sun.messaging.ConnectionFactory(); //create an MQ connection. com.sun.messaging.jms.Connection connection = (com.sun.messaging.jms.Connection )factory.createConnection(); //construct an MQ event listener. The listener implements //com.sun.messaging.jms.notification.EventListener interface. com.sun.messaging.jms.notification.EventListener eListener = new ApplicationEventListener(); //set event listener to the MQ connection. connection.setEventListener ( eListener );
이 예에서 응용 프로그램은 해당 이벤트 수신기가 연결 이벤트를 응용 프로그램의 로깅 시스템에 기록하도록 선택합니다.
public class ApplicationEventListener implements com.sun.messaging.jms.notification.EventListener { public void onEvent ( com.sun.messaging.jms.notification.Event connEvent ) { log (connEvent); } private void log ( com.sun.messaging.jms.notification.Event connEvent ) { String eventCode = connEvent.getEventCode(); String eventMessage = connEvent.getEventMessage(); //write event information to the output stream. } }