Azure服務總線重試策略的minbackoff不起作用？

我試圖讓一個隊列的重試邏輯工作，我遇到了問題。 minBackoff變量似乎並不實際工作。我在我的日誌中看到，接收到的消息失敗，然後幾乎立即重試。我的minBackoff設置爲600秒。Azure服務總線重試策略的minbackoff不起作用？

下面是設置了查詢代碼：

NamespaceManager nsManager = NamespaceManager.CreateFromConnectionString(connectionString); 
     nsManager.Settings.RetryPolicy = new RetryExponential(minBackoff: TimeSpan.FromSeconds(5), 
                  maxBackoff: TimeSpan.FromSeconds(30), 
                  maxRetryCount: 3); 

     if (!nsManager.QueueExists(queueName)) 
     { 
      nsManager.CreateQueue(queueName); 
     } 
     else 
     { 
      nsManager.DeleteQueue(queueName); 
      nsManager.CreateQueue(queueName); 
     } 

     QueueClient client = QueueClient.CreateFromConnectionString(connectionString, queueName); 


     client.RetryPolicy = new RetryExponential(minBackoff: TimeSpan.FromSeconds(15), 
                 maxBackoff: TimeSpan.FromSeconds(600), 
                 maxRetryCount: 3); 
     for (int i = 0; i < 2000; i++) 
     { 
      UserCreationSubmitted creationMessage = new UserCreationSubmitted() 
      { 
       CreationStatus = "Step 1", 
       Id = Guid.NewGuid(), 
       UserName = "user number " + i, 
       Userid = Guid.NewGuid() 
      }; 

      BrokeredMessage message = new BrokeredMessage(creationMessage); 
      client.Send(message); 

     }

下面是不工作如何，我認爲它應該代碼...

client.RetryPolicy = new RetryExponential(minBackoff: TimeSpan.FromSeconds(15), 
                 maxBackoff: TimeSpan.FromSeconds(600), 
                 maxRetryCount: 3); 

     client.OnMessage(message => 
     { 

      UserCreationSubmitted msg = message.GetBody<UserCreationSubmitted>(); 
      Console.WriteLine("------------------------------"); 
      Console.WriteLine($"Body {msg.UserName}"); 

      Random rnd = new Random(); 
      int ranNum = rnd.Next(0, 9); 
      if (msg.UserName.Contains(ranNum.ToString())) 
      { 
       Console.WriteLine("!!!Error!!!"); 
       Console.WriteLine("------------------------------"); 
       throw new Exception(); 
      } 
     });

有沒有人有一個想法，爲什麼minbackoff和maxbackoff在這裏似乎並不實際工作？奇怪的是，maxRetryCount像一個騎兵一樣工作，所以我想這絕對是我的實現中的一些東西，導致其他人無法工作。

來源

2016-11-16 Debacle

RetryExponential由ASB客戶端用於重試，當收到故障時消息正在發生。在你的代碼中，在收到消息的事實之後，在OnMessage API回調中處理期間引發異常。 OnMessage API將abandon the message，導致它立即顯示。

有幾個選項，你可以採取：

克隆的消息，設置ScheduledEnqueueTimeUtc到你想要的延遲，發送，然後完成原始郵件。
推遲發送消息，但您只能通過SequenceNumber接收。在這種情況下，您可以創建一個包含原始消息序列號作爲有效負載的新消息，安排新消息併發送它。這樣你就可以在原始信息上得到準確的計數。

理想情況下，放棄帶有時間跨度的消息會很好，但對於當前的API來說這是不可能的。

來源

2016-11-17 17:36:22

非常感謝，這是非常有幫助 – Debacle

@Debacle歡迎您 –

Azure服務總線重試策略的minbackoff不起作用？

回答

相關問題