메시지 유실 여부 확인

브로커 도메인을 통해 플로우하는 메시지를 보호하는 것이 중요합니다. 이는 응용프로그램에서 생성한 메시지 및 구성요소 간 통신에 내부적으로 사용된 메시지 모두에 해당됩니다. 구성요소 간에 내부적으로 사용되는 메시지는 항상 WebSphere MQ 프로토콜을 사용합니다. 응용프로그램 메시지는 지원되는 모든 전송 프로토콜을 사용할 수 있습니다.

WebSphere MQ를 거치는 응용프로그램 및 내부 메시지의 경우, 다음과 같은 두 가지 기술은 메시지 유실을 방지합니다.

이 옵션을 사용하는 방법에 대한 자세한 정보는 WebSphere MQ 시스템 관리 안내서를 참조하십시오.

내부 메시지

WebSphere Message Broker 구성요소는 WebSphere MQ 메시지를 사용하여 브로커 프로세스와 서브시스템, 구성 관리자사용자 이름 서버 간의 데이터 및 이벤트와 통신합니다. 구성요소는 WebSphere MQ 기능을 사용하여 메시지가 손실되지 않도록 방지합니다. 내부 메시지의 유실을 방지하기 위해 WebSphere MQ 또는 WebSphere Message Broker 구성 시 추가 단계를 수행하지 않아도 됩니다.

응용프로그램 메시지

응용프로그램 메시지 전달이 중요한 경우, 응용프로그램 및 이들이 사용하는 메시지 플로우에서 메시지가 손실되지 않도록 설계해야 합니다. 사용하는 기술은 응용프로그램에서 사용되는 프로토콜에 따라 다릅니다.

WebSphere MQ Enterprise TransportWebSphere MQ Mobile Transport
WebSphere MQWebSphere MQ Everyplace 프로토콜을 통해 메시지를 승인하는 내장 입력 노드를 사용할 경우, 다음과 같은 지시사항 및 권장사항을 사용할 수 있습니다.
  • 지속 메시지 사용

    WebSphere MQ 메시징 제품은 시스템에서 메시지의 수명을 정의하고 메시지 무결성을 보장하는 메시지 지속성을 제공합니다. 비지속 메시지는 시스템 또는 큐 관리자 장애 발생 시 유실됩니다. 지속 메시지는 장애가 발생할 경우 항상 복구됩니다.

    다음 방법으로 메시지 지속성을 제어할 수 있습니다.
    • 메시지가 지속임을 나타내기 위해 MQI 또는 AMI를 사용하여 큐에 메시지를 넣는 응용프로그램을 프로그래밍하십시오.
    • 메시지가 지속성을 갖는 입력 큐를 디폴트 설정으로 정의하십시오.
    • 지속 메시지를 핸들링하도록 출력 노드를 구성하십시오.
    • 메시지 지속을 요청하는 subscriber 응용프로그램을 프로그래밍하십시오.

    입력 노드가 입력 큐에서 메시지를 읽는 경우, 디폴트 조치는 WebSphere MQ 메시지 헤더(MQMD)에 정의된 지속성을 사용하는 것이며, 이는 메시지를 작성하는 응용프로그램 또는 입력 큐의 디폴트 지속성에 의해 설정됩니다. 후속 메시지 처리 노드에서 변경한 경우를 제외하고, 메시지는 메시지 플로우 전반에 걸쳐 이 지속성을 보유합니다.

    메시지 플로우가 출력 노드에서 종료되면 각 메시지의 지속 값을 대체할 수 있습니다. 이 노드에는 출력 큐에 메시지를 넣을 때 필수 값 또는 디폴트 값으로 각 메시지의 메시지 지속성을 지정할 수 있는 등록 정보가 있습니다. 디폴트를 지정할 경우, 메시지는 메시지를 기록하는 큐에 대해 정의된 지속 값을 사용합니다.

    Publication 노드를 통해 메시지를 전달할 경우, subscriber로 송신된 메시지의 지속 여부는 subscriber의 등록 옵션에 의해 판별됩니다. Subscriber가 지속 메시지 전달을 요청했을 때 수행할 권한이 내재된(상속된) ACL에 의해 부여되었으면, 메시지는 기존의 지속 등록 정보에 관계없이 지속적으로 전달됩니다. 또한 사용자가 비지속 메시지 전달을 요청한 경우, 기존 지속 등록 정보에 관계없이 메시지가 비지속적으로 전달됩니다.

    메시지 플로우가 새 메시지를 작성하는 경우(예: Compute 노드에서), 새 메시지 MQMD의 지속성은 수신 메시지의 MQMD에 있는 지속성에서 복사됩니다.

  • 동기점 제어하에 메시지 처리

    메시지 플로우의 디폴트 조치는 브로커 제어 트랜잭션 내의 동기점 아래에 수신되는 메시지를 처리하는 것입니다. 이는 어떠한 이유로든지 처리에 실패하는 메시지는 브로커에 의해 백아웃된다는 것을 의미합니다. 메시지가 동기점 아래에 수신되기 때문에 실패한 메시지는 입력 큐에 다시 넣어져 다시 처리될 수 있습니다. 처리에 실패한 경우, 이 메시지 플로우에 대해 적합한 오류 핸들링 프로시저(메시지 플로우를 구성한 방법 또는 브로커에 의해 정의됨)가 실행됩니다.

    입력 노드 처리에 대한 자세한 내용은 입력 노드에서 오류 관리를 참조하십시오.

WebSphere MQ Telemetry Transport
MQIsdp 프로토콜을 사용하여 원격(telemetry) 디바이스에서 메시지를 승인하는 내장 입력 노드인 SCADAInput을 사용 중인 경우, 이 프로토콜에는 큐의 개념이 없습니다. 클라이언트는 노드가 대기하는 포트 번호를 지정하여 SCADAInput 노드에 연결합니다. 메시지는 clientId를 사용하여 클라이언트로 송신됩니다. 그러나 지속성과 유사한 SCADA subscription 내에 최대 QoS(Quality of Service)를 지정할 수 있습니다.
  • QoS0 비지속.
  • QoS1 지속, 두 번 이상 전달될 수 있습니다.
  • QoS2 한 번만 전달됩니다.

지속 SCADA 메시지를 publish하면, 클라이언트가 승인할 수 있는 최상위 레벨로 다운그레이드될 수 있습니다. 일부 상황에서 이는 메시지가 비지속이 될 수 있음을 의미합니다.

WebSphere MQ Real-time Transport, WebSphere MQ Multicast TransportWebSphere MQ Web Services TransportWebSphere MQ Multicast Transport
JMS로부터 메시지를 승인하여 응용프로그램을 멀티캐스트하는 내장 입력 노드인 Real-timeInput과 Real-timeOptimizedFlow 또는 웹 서비스 응용프로그램으로부터 메시지를 승인하는 HTTP Input 및 HTTPRequest 노드를 사용 중인 경우, 메시지 유실을 방지하는 데 사용 가능한 기능이 없습니다. 그러나 자체 오류를 핸들링하도록 메시지 플로우를 구성하여 복구 프로시저를 제공할 수 있습니다.
다른 전송 및 프로토콜
다른 전송 프로토콜로부터 메시지를 수신하는 자신의 사용자 정의 입력 노드를 작성한 경우, 전송 프로토콜에서 제공하는 지원에 의존하거나 자신의 복구 프로시저를 제공해야 합니다.
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
ac00420_