수신기와 플레이어는 함께 작업하여 포이즌 메시지를 처리합니다. 재생 중인 트랜잭션이 실패하면 메시지 큐 입력 메시지를 다시 입력 큐로 이동합니다. 서버 구성 요소에서 실패한 HRESULT를 받거나 예외를 catch하는 경우 플레이어는 트랜잭션을 중단합니다. 문제가 지속되면 수신기는 다음 패턴으로 지속적으로 반복될 수 있습니다.
- 메시지 큐에서 제거
- 개체 인스턴스화
- 롤백을 겪습니다.
- 메시지를 큐의 맨 위에 다시 배치합니다.
큐에 대기 중인 구성 요소 서비스는 일련의 애플리케이션별 재시도 큐를 사용하여 이 오류를 처리합니다. 구성 요소가 설치될 때 생성되는 각 애플리케이션에는 다음과 같이 7개의 큐가 있습니다.
일반 입력 큐입니다. 이 큐의 이름은 COM+ 애플리케이션 이름입니다. 메시지 큐 공용 큐입니다.
첫 번째 다시 시도 큐입니다. 일반 입력 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 1분 후에 처리됩니다. 두 번째 재시도 큐의 뒤쪽으로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName _0에. 이 큐는 프라이빗 메시지 큐 큐입니다.
두 번째 다시 시도 큐입니다. 첫 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 2분 후에 처리됩니다. 세 번째 재시도 큐의 뒤쪽으로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName _1에. 이 큐는 프라이빗 메시지 큐 큐입니다.
세 번째 다시 시도 큐입니다. 두 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 4분 후에 처리됩니다. 네 번째 재시도 큐의 뒤쪽으로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName _2에. 이 큐는 프라이빗 메시지 큐 큐입니다.
네 번째 다시 시도 큐입니다. 세 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 8분 후에 처리됩니다. 다섯 번째 재시도 큐로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName _3에. 이 큐는 프라이빗 메시지 큐 큐입니다.
다섯 번째 다시 시도 큐입니다. 네 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 16분 후에 처리됩니다. 최종 휴식 큐로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도하면 됩니다. 이 큐의 이름은 ApplicationName _4에. 프라이빗 메시지 큐 큐입니다.
애플리케이션별 최종 휴식 큐입니다. 다섯 번째 재시도 큐에서 시도할 때 트랜잭션이 반복적으로 중단되면 메시지가 여기에 이동됩니다. 이 큐의 이름은 ApplicationName _DeadQueue. 프라이빗 메시지 큐 큐입니다. 최종 휴식 큐는 큐 수신기에서 처리되지 않습니다. 메시지는 수동으로 이동되거나(큐에 대기 중인 구성 요소 메시지 이동기 유틸리티에 의해) 메시지 큐 탐색기에서 제거될 때까지 여기에 유지됩니다.
모든 재시도 시도가 실패할 것이 분명하기 때문에 재생할 수 없는 메시지는 모든 재시도 수준을 거치지 않고 애플리케이션별 최종 휴식 큐로 직접 이동할 수 있습니다.
플레이어는 COM+ 이벤트를 발행하여 관련자에게 메시지를 재생할 수 없음을 알립니다. COM+ 이벤트는 다음과 같은 상황에서 발생합니다.
- 트랜잭션이 중단되는 경우
- 메시지가 한 큐에서 다른 큐로 이동되는 경우
- 메시지가 최종 휴식 큐에 저장되는 경우
한 큐에서 다른 큐로 이동하기 전에 메시지를 수정할 수 있습니다. COM+ 큐에 대기 중인 구성 요소 보안 메커니즘을 사용하면 메시지를 이동하여 큐를 다시 시도한 다음 애플리케이션의 초기 입력 큐에 다시 삽입할 수 있습니다. 대기 중인 구성 요소 보안에 대한 자세한 내용은 대기 중인 구성 요소 보안 참조하세요.
재시도 큐는 애플리케이션이 Component Services 관리 도구 또는 COM+ 관리 SDK 함수를 사용하여 큐로 표시될 때 주 애플리케이션 큐와 함께 만들어집니다. 큐에 대기 중인 구성 요소 서비스를 사용하면 재시도 큐를 삭제할 수 있도록 하여 재시도 메커니즘의 유연성을 제공합니다. 예를 들어 모든 재시도 큐가 삭제되면 영구적으로 중단되는 메시지가 애플리케이션 큐에서 애플리케이션별 최종 휴식 큐로 직접 이동됩니다. 재시도 큐를 하나 이상 제거하면 재시도 횟수와 길이를 줄일 수 있습니다. 큐가 재시도 시퀀스에서 제거되면 나머지 큐의 타이밍은 재시도 큐 시퀀스의 위치에 해당합니다. 예를 들어 ApplicationName _1에다시 시도 큐를 제거하고 ApplicationName _2를ApplicationName _3을경우 ApplicationName_4의 메시지는 큐가 두 번째 재시도 큐인 것처럼 처리됩니다.
재시도 메커니즘은 가능한 경우 메시지를 완료하도록 설계되었습니다. 경우에 따라 메시지가 성공하지 못할 수 있습니다. 예를 들어, 클라이언트가 자금이 부족한 계정에서 돈을 인출하려고 할 수 있습니다. 이러한 경우 다음과 같은 여러 가지 방법으로 오류를 처리할 수 있습니다.
- 진단 생성 및 경고 발급
- 보상 트랜잭션 만들기
- 문제를 무시하고 메시지 해제
클라이언트 쪽 영구 오류와 마찬가지로 대기 중인 구성 요소 서비스를 사용하면 예외 클래스를 구성 요소와 연결할 수 있습니다. 예외 클래스는 구성 요소 서비스 관리 도구의 구성 요소 속성 페이지에서 고급 탭을 사용하거나 COM+ 관리 함수를 사용하여 구성 요소와 연결됩니다. 예외 클래스를 사용하면 메시지가 다시 시도되고 해당 메시지가 애플리케이션별 최종 휴식 큐로 이동하기 전에 개발자가 제어할 수 있습니다. 예외 클래스에 대한 자세한 내용은 영구 Client-Side 오류참조하세요.
다음은 서버 쪽 예외 처리에 대한 이벤트 시퀀스입니다.
- 메시지는 사용 가능한 애플리케이션별 재시도 큐를 통해 이동됩니다.
- 마지막 재시도 큐에 대한 최종 재시도에 실패합니다.
- 대기 중인 구성 요소 서비스 런타임은 메시지에서 대상 구성 요소를 검색하고 예외 클래스를 확인합니다.
- 런타임은 예외 클래스를 인스턴스화합니다.
- 런타임 쿼리는 예외 클래스에서 IPlaybackControl.
- 런타임 호출은 예외 클래스에서 IPlaybackControl::FinalServerRetry.
- 런타임은 메시지에서 예외 클래스로의 모든 속성 및 메서드 호출을 재생합니다.
- 4~6단계가 성공하지 못하면 런타임은 메시지를 애플리케이션별 최종 휴식 큐로 이동합니다.
위에서 설명한 프로세스에 개입해야 하거나 최종 휴식 큐에서 포이즌 메시지를 이동해야 하는 경우 메시지 이동기 유틸리티를 사용합니다. 메시지 이동기 유틸리티에 대한 자세한 내용은 오류 처리 참조하세요.
관련 항목