발신 전화를 처리하기 위해 프로젝트에 새 작업자 역할을 추가했습니다. 서비스 버스 대기열을 만들기 위해 호출을 가져옵니다.
나는 그것이 작동하는지 확인할 수 있도록 대기열에 물건을 던지는 작은 콘솔 앱을 만들었습니다. 불행히도 내 앱이 대기열에 넣은 것은 즉시 (또는 거의 즉시?) 배달 못한 편지 대기열에 넣는 것처럼 보입니다. 대기열의 속성을 살펴 봤는데
MessageCount 5
ActiveMessageCount 0
DeadLetterMessageCount 5
TransferMessageCount 0
AvailabilityStatus Available
EnableDeadLetteringOnMessageExpiration False
작업자 역할은 대기열에서 항목을 가져 오려고하지만 가져 오는 것은 모두 null입니다.
대기열 설정은 작동중인 다른 대기열과 동일합니다. 큐에 넣는 개체는 [MessageContract] 및 [Serializable]로 표시된 거의 모든 기본 요소로 구성됩니다. 모든 멤버는 [MessageHeader]로 표시됩니다.
나는 또한 우리가 다른 대기열에 사용하는 객체를 사용하여 어떤 일이 발생하는지 확인하고 즉시 죽은 문자도 보았습니다.
이해가 안 돼요. 개체는 대기열 크기가 커짐에 따라 명확하게 대기열로 이동하고 있습니다. 그러나 그것은 바로 죽은 편지에 불과하며 시간 초과 외에 어떤 일이 일어날 수 있는지 모르겠습니다.
추가 정보 : Service Bus Explorer를 사용하여 살펴본 결과 MaxDeliveryCountExceeded로 인해 메시지가 데드-레터로 표시되는 것 같습니다. 이는 메시지 수신이 10 회 이상 실패하면 배달 못한 편지 대기열로 이동한다는 의미로 보입니다. 그래서 그 부분은 해결되었지만 작업자 역할 코드에 디버그 지점을 넣었고 거기에서 오류가 발생하지 않았습니다. 나의
BrokeredMessage message = Client.Receive()
항상 null을 반환하므로 잘못된 일을 할 시간이 없습니다. 실제 Receive () 호출에서 뭔가 잘못되었다고 생각합니까?
MessageContract에 Uri가 있으면 역 직렬화 프로세스 어딘가에서 실패 할 수 있습니다. 그래서 Client.Receive (); 10 번 시도했지만 항상 실패했고 그 다음에는 데드 레터가되었습니다. Uris가 Serializable이라고 생각했지만 서비스 버스를 통해 연결하는 데 문제가있는 것 같습니다. 어쨌든 내 상황에서 Uri를 문자열로 변경하는 것은 큰 문제가 아니었고 모든 것이 괜찮습니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다