2017-01-23 194 views
4

我在Azure中創建了一個服務總線隊列,它運行良好。如果郵件在默認嘗試(10次)內未收到,則會將郵件正確地移動到死信隊列中。重新提交來自死信隊列的消息 - Azure服務總線

現在,我想從死信隊列中重新提交此消息回到它發出的隊列,看看它是否再次有效。我已經嘗試使用服務總線瀏覽器。但它會立即移到死信隊列中。

是否有可能做同樣的事情,如果有的話如何?

回答

1

服務總線瀏覽器工具始終會在修復並重新提交來自死信隊列的消息時創建原始消息的克隆。它與默認的Service Bus消息不能提供任何消息修復和重新提交機制不同。我建議你調查爲什麼當你重新提交郵件時,你的郵件會在deadletter隊列以及它的克隆中結束。希望這可以幫助!

+2

原始郵件已經死了,因爲它試圖傳遞10次,並且由於某種原因,服務不可用。但現在服務又回來了。消息的克隆也顯示了與原始消息相同的錯誤,並且只需一次嘗試,計數就已經是11.因此,我假設傳遞消息的計數不會在克隆消息中復位 –

2

你需要發送一個具有相同有效載荷的新消息。 ASB設計不支持消息重新提交。

1

聽起來這可能與ASB的「重複信息檢測」功能有關。

當您在ServiceBus資源管理器中重新提交郵件時,它將克隆郵件,從而新郵件將具有與原郵件在死郵件隊列中相同的標識。

如果您在隊列/主題上啓用了「需要重複檢測」,並且您嘗試在「重複檢測歷史記錄時間窗口」內重新提交郵件,則郵件將立即再次移至死信號隊列。

如果您想使用Service Bus Explorer重新提交deadletter消息,那麼我認爲您必須在隊列/主題上禁用「需要重複檢測」。

0

如果您直接將BrokeredMessage從死信隊列移動到活隊列,則可能是「重複消息檢測」爲Peter Berggreen,或者更有可能,那麼DeliveryCount仍然會達到最大值,並且它將返回到死信隊列。

將BrokeredMessage從死信隊列中拉出,使用GetBody()獲取內容,在新的BrokeredMessage中創建該數據並將其發送到隊列。您可以通過使用peek從死信隊列中獲取消息內容,然後將新消息發送到實時隊列,然後從死信隊列中刪除消息,以安全的方式執行此操作。這樣,如果由於某種原因無法寫入實時隊列,您將不會丟失關鍵數據。

對於新的BrokeredMessage,您應該不會遇到「重複的郵件檢測」問題,並且DeliveryCount將被重置爲零。