Azure에서 서비스 버스 큐를 만들었고 제대로 작동합니다. 그리고 메시지가 기본 시도 (10 회) 내에 전달되지 않으면 메시지를 데드 레터 대기열로 올바르게 이동하고 있습니다.데드 레터 큐에서 메시지 다시 보내기 - Azure 서비스 버스
이제는 데드 레터 큐에서이 메시지를 원래 있던 큐로 다시 보내고 다시 작동하는지 확인하고 싶습니다. 나는 서비스 버스 탐색기를 사용하여 같은 것을 시도했다. 그러나 그것은 즉시 데드 레터 큐로 이동합니다.
동일한 작업을 수행 할 수 있습니까? 그렇다면 어떻게해야합니까?
서비스 버스 탐색기 도구는 배달 못 한 편지 대기열에서 메시지를 복구하고 다시 제출할 때 항상 원래 메시지의 복제본을 만듭니다. 기본적으로 Service Bus 메시징은 메시지 복구 및 다시 제출 메커니즘을 제공하지 않기 때문에 다른 것은 아닙니다. 메시지를 다시 제출할 때 데드 레터 대기열과 클론에서 메시지가 왜 끝나는 지 조사하도록 제안합니다. 희망이 도움이!
동일한 페이로드로 새 메시지를 보내야합니다. ASB는 메시지 재전송을 지원하지 않습니다.
ASB의 "중복 메시지 감지"기능과 관련이있는 것 같습니다.
ServiceBus 탐색기에서 메시지를 다시 전송하면 메시지가 복제되므로 새 메시지는 교착 상태 대기열의 원래 메시지와 동일한 ID를 갖게됩니다.
대기열/주제에서 "중복 감지가 필요합니다"를 활성화 한 상태에서 "중복 검색 내역 시간 창"에서 메시지를 다시 전송하려고 시도하면 메시지가 즉시 대기열 대기열로 다시 이동합니다.
서비스 버스 탐색기를 사용하여 부재 중 메시지를 다시 보내려면 대기열/주제에서 "중복 감지 필요"를 비활성화해야한다고 생각합니다.
"duplicate message detection"이 Peter Berggreen으로 표시 될 수 있습니다. 또는 데드 레터 대기열에서 실시간 대기열로 BrokeredMessage를 직접 이동하는 경우 DeliveryCount가 여전히 최대 일 때 데드 레터로 되돌아 오는 경우가 많습니다 열.
데드 레터 큐에서 BrokeredMessage를 당겨 GetBody()를 사용하여 콘텐츠를 가져 와서 해당 데이터로 새 BrokeredMessage를 만들고 큐에 보냅니다. 죽은 편지 대기열에서 메시지 내용을 가져 와서 죽은 편지 대기열에서 메시지를 제거하기 전에 라이브 대기열에 새 메시지를 보내려면 peek을 사용하여 안전한 매너에서이 작업을 수행 할 수 있습니다. 어떤 이유로 그것이 라이브 대기열에 쓰지 못할 경우 중요한 데이터가 손실되지 않습니다.
새 BrokeredMessage를 사용하면 "중복 메시지 감지"문제가 발생하지 않고 DeliveryCount가 0으로 재설정됩니다.
원래 메시지는 10 번 배달을 시도했기 때문에 문자 메시지로 표시되어 어떤 이유로 서비스를 사용할 수 없었습니다. 하지만 이제 서비스가 다시 시작됩니다. 메시지의 복제본은 원래 메시지와 동일한 오류를 보여 주며 단일 시도로 인해 이미 수는 11입니다. 따라서 전달 된 메시지의 개수가 복제 메시지에서 재설정되지 않은 것으로 가정합니다 –