다음을 통해 공유

Server-Side 오류

  • 아티클

수신기와 플레이어는 포이즌 메시지를 처리하기 위해 함께 작동합니다. 재생 중인 트랜잭션이 실패하면 메시지 큐는 입력 메시지를 입력 큐로 다시 이동합니다. 서버 구성 요소에서 실패한 HRESULT를 수신하거나 예외를 catch하는 경우 플레이어는 트랜잭션을 중단합니다. 문제가 지속되면 수신기는 다음 패턴으로 계속 반복할 수 있습니다.

  • 메시지 큐에서 제거
  • 개체 인스턴스화
  • 롤백을 겪습니다.
  • 메시지를 큐 맨 위에 다시 배치합니다.

큐에 대기 중인 구성 요소 서비스는 일련의 애플리케이션별 재시도 큐를 사용하여 이 오류를 처리합니다. 구성 요소가 설치될 때 생성되는 각 애플리케이션에는 다음과 같이 7개의 큐가 있습니다.

  1. 일반 입력 큐입니다. 이 큐의 이름은 COM+ 애플리케이션 이름입니다. 메시지 큐 공용 큐입니다.

  2. 첫 번째 다시 시도 큐입니다. 일반 입력 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기로 이동됩니다. 이 큐의 메시지는 1분 후에 처리됩니다. 두 번째 재시도 큐의 뒤쪽으로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName_0입니다. 이 큐는 프라이빗 메시지 큐 큐입니다.

  3. 두 번째 다시 시도 큐입니다. 첫 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 2분 후에 처리됩니다. 세 번째 재시도 큐의 뒤쪽으로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName_1입니다. 이 큐는 프라이빗 메시지 큐 큐입니다.

  4. 세 번째 재시도 큐입니다. 두 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 4분 후에 처리됩니다. 네 번째 다시 시도 큐의 뒤쪽으로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName_2입니다. 이 큐는 프라이빗 메시지 큐 큐입니다.

  5. 네 번째 다시 시도 큐입니다. 세 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기에 이동됩니다. 이 큐의 메시지는 8분 후에 처리됩니다. 다섯 번째 재시도 큐로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도할 수 있습니다. 이 큐의 이름은 ApplicationName_3입니다. 이 큐는 프라이빗 메시지 큐 큐입니다.

  6. 다섯 번째 다시 시도 큐입니다. 네 번째 재시도 큐에서 메시지를 처리할 때 트랜잭션이 반복적으로 실패하면 메시지가 여기로 이동됩니다. 이 큐의 메시지는 16분 후에 처리됩니다. 최종 휴식 큐로 이동하기 전에 이 큐에서 메시지를 세 번 다시 시도하면 됩니다. 이 큐의 이름은 ApplicationName_4입니다. 프라이빗 메시지 큐 큐입니다.

  7. 애플리케이션별 최종 휴식 큐입니다. 다섯 번째 재시도 큐에서 시도할 때 트랜잭션이 반복적으로 중단되면 메시지가 여기에 이동됩니다. 이 큐의 이름은 ApplicationName_DeadQueue. 프라이빗 메시지 큐 큐입니다. 최종 휴식 큐는 큐 수신기에서 서비스되지 않습니다. 메시지는 수동으로 이동하거나(큐에 대기 중인 구성 요소 메시지 이동기 유틸리티에 의해) 메시지 큐 Explorer 제거될 때까지 여기에 유지됩니다.

모든 재시도 시도가 실패할 것이 분명하기 때문에 재생할 수 없는 메시지는 모든 재시도 수준을 거치지 않고 애플리케이션별 최종 휴식 큐로 직접 이동할 수 있습니다.

플레이어는 COM+ 이벤트를 발행하여 관련자에게 메시지를 재생할 수 없음을 알립니다. COM+ 이벤트는 다음과 같은 경우에 발생합니다.

  • 트랜잭션이 중단되는 경우
  • 메시지가 한 큐에서 다른 큐로 이동되는 경우
  • 메시지가 최종 휴지 큐에 저장되는 경우

한 큐에서 다른 큐로 이동하기 전에 메시지를 수정할 수 있습니다. COM+ 큐에 대기 중인 구성 요소 보안 메커니즘을 사용하면 메시지를 이동하여 큐를 다시 시도한 다음 애플리케이션의 초기 입력 큐에 다시 삽입할 수 있습니다. 대기 중인 구성 요소 보안에 대한 자세한 내용은 대기 중인 구성 요소 보안을 참조하세요.

재시도 큐는 애플리케이션이 Component Services 관리 도구 또는 COM+ 관리 SDK 함수를 사용하여 큐에 대기된 것으로 표시되면 기본 애플리케이션 큐와 함께 만들어집니다. 큐에 대기 중인 구성 요소 서비스를 사용하면 재시도 큐를 삭제하여 재시도 메커니즘을 유연하게 사용할 수 있습니다. 예를 들어 모든 재시도 큐가 삭제되면 영구적으로 중단되는 메시지가 애플리케이션 큐에서 애플리케이션별 최종 휴식 큐로 직접 이동됩니다. 재시도 큐를 하나 이상 제거하면 재시도 횟수와 길이를 줄일 수 있습니다. 큐가 재시도 시퀀스에서 제거되면 나머지 큐의 타이밍은 재시도 큐 시퀀스의 위치에 해당합니다. 예를 들어 재시도 큐 ApplicationName_1, ApplicationName_2 및 ApplicationName_3을 제거하면 ApplicationName_4의 메시지는 큐가 두 번째 재시도 큐인 것처럼 처리됩니다.

재시도 메커니즘은 가능한 경우 메시지를 완료하도록 설계되었습니다. 경우에 따라 메시지가 성공하지 못할 수 있습니다. 예를 들어, 고객이 자금이 부족한 계좌에서 돈을 인출하려고 할 수 있습니다. 이러한 경우 다음을 포함하여 여러 가지 방법으로 오류를 처리할 수 있습니다.

  • 진단 생성 및 경고 실행
  • 보상 트랜잭션 만들기
  • 문제를 무시하고 메시지를 해제합니다.

클라이언트 쪽 영구 오류와 마찬가지로 대기 중인 구성 요소 서비스를 사용하면 예외 클래스를 구성 요소와 연결할 수 있습니다. 예외 클래스는 구성 요소 서비스 관리 도구의 구성 요소 속성 페이지에서 고급 탭을 사용하거나 COM+ 관리 함수를 사용하여 구성 요소와 연결됩니다. 예외 클래스를 사용하면 메시지를 다시 시도한 후 해당 메시지가 애플리케이션별 최종 휴식 큐로 이동하기 전에 개발자가 제어할 수 있습니다. 예외 클래스에 대한 자세한 내용은 영구적 Client-Side 오류를 참조하세요.

다음은 서버 쪽 예외 처리에 대한 이벤트 시퀀스입니다.

  1. 메시지는 사용 가능한 애플리케이션별 재시도 큐를 통해 이동됩니다.
  2. 마지막 다시 시도 큐에 대한 마지막 다시 시도가 실패합니다.
  3. 큐에 대기 중인 구성 요소 서비스 런타임은 메시지에서 대상 구성 요소를 검색하고 예외 클래스를 확인합니다.
  4. 런타임은 예외 클래스를 인스턴스화합니다.
  5. 런타임은 예외 클래스에서 IPlaybackControl 을 쿼리합니다.
  6. 런타임은 예외 클래스에서 IPlaybackControl::FinalServerRetry 를 호출합니다.
  7. 런타임은 메시지에서 예외 클래스로의 모든 속성 및 메서드 호출을 재생합니다.
  8. 4~6단계가 성공하지 못하면 런타임은 메시지를 애플리케이션별 최종 휴식 큐로 이동합니다.

위에서 설명한 프로세스에 개입해야 하거나 포이즌 메시지를 최종 휴식 큐에서 이동해야 하는 경우 메시지 이동기 유틸리티를 사용합니다. 메시지 이동기 유틸리티에 대한 자세한 내용은 오류 처리를 참조하세요.

클라이언트 쪽 오류

영구 Client-Side 실패