Azure服務總線，確定OnMessage是否停止處理

使用Azure ServiceBus和OnMessage調用我正在尋找一種方法來確定OnMessage事件泵是否停止從隊列中讀取數據。Azure服務總線，確定OnMessage是否停止處理

我們到的onMessage連接的配置如下：

protected virtual void DoSubscription(string queueName, Func<QueueRequest, bool> callback) 
{ 
    var client = GetClient(queueName, PollingTimeout); 
    var transformCallback = new Action<BrokeredMessage>((message) => 
    { 
     try 
     { 
      var request = message.ToQueueRequest(); 
      if (callback(request)) 
      { 
       message.Complete(); 
      } 
      else 
      { 
       message.Abandon(); 
       Log.Warn("DoSubscription: Message Failed to Process Gracefully: {0}{1}", Environment.NewLine, JsonConvert.SerializeObject(request)); 
      } 
     } 
     catch (Exception ex) 
     { 
      Log.Error("DoSubscription: Message Failed to Process With Exception:", ex); 
      message.Abandon(); 
     } 
    }); 
    var options = new OnMessageOptions 
    { 
     MaxConcurrentCalls = _config.GetInt("MaxThreadsPerQueue"), 
     AutoComplete = false, 
     AutoRenewTimeout = new TimeSpan(0,0,1) 
    }; 
    options.ExceptionReceived += OnMessageError; 
    client.OnMessage(transformCallback, options); 
}

我們所遇到的問題是一段時間沒有消息正在排隊進行排隊未能通過的onMessage事件被拾起新郵件後泵直到應用程序重新啓動。

我知道有些方法可以使用Worker Roles來實現這一點，但是出於監視和管理的目的，我們決定在Web應用程序的Application Start中實現這一點。

來源

2015-07-10 VulgarBinary

您是否檢查死郵隊隊列？如果那裏有消息，你應該能夠看到你的消息處理失敗的原因。 – mert

在DL他們只是超時。以編程方式，該過程剛剛停止。 – VulgarBinary

因此，在與Microsoft的Azure支持團隊通話後，如果發生OnMessage或OnMessageAsync錯誤，則無法捕獲事件。由於這些不會阻止調用，因此它會啓動事件泵並返回到正在執行的線程，這會產生一個挑戰，以確定OnMessage *是否正在完成它的工作。從微軟

的建議是：

創建自己的實現，其暴露的OnClose上，您可以處理*方法QueueClientBase類的。但是，在這樣做時，您必須自己處理郵件信封。
在單獨的線程循環中使用OnReceive，您可以自行捕獲錯誤並立即重試。

但是，我確實探索了一些針對OnMessage的子彈打樣，並發現了一些減輕了我的恐懼的東西。

的onMessage是令人難以置信的容錯
- 我uplugged以太網電纜從我的筆記本電腦無線關閉，這打破了的onMessage對服務總線隊列連接。等待10分鐘後，我再次插入以太網電纜，OnMessage立即開始處理排隊的元素。
在消息驚人的是相當穩定。它已經在global.asax.cs應用程序啓動中運行，爲了簡化工作日，將Factory IdleTimeout設置爲24小時，而不必在72小時內重新啓動Web應用程序。

總而言之，我現在要繼續使用OnMessage/OnMessageAsync並留意它。如果我看到的問題改變了我對OnMessage的看法，我會更新它。

另外 - 確保在Azure網站中將「Always On」配置選項設置爲「On」時，是否使用OnMessage進行永久監聽。否則，除非Web請求進入，否則將丟棄OnMessage，並在Web應用程序被HTTP請求重新喚醒之前不再處理消息。

來源

2015-07-16 21:01:38 VulgarBinary

經過一個多月的不間斷處理，OnMessage一直沒有問題。在這個交叉點，我會說，使用OnMessage是可以接受的，而不需要非常關心確定停止狀態的能力。爲了安全起見，我們有一個冗餘檢查隊列中最老的元素，如果它的年齡超過了配置的時間，它會通知我們。在我們的案例中，調查結果加上通知表已足以繼續採用這種方法。 – VulgarBinary

另一個後續......現在已經過了一年多了。 OnMessage的解決方案仍然沒有失敗或失敗。我支持我的初步聲明，OnMessage足夠有彈性，可以不受改變的生產用途。 – VulgarBinary

你在什麼過程中實例化QueueClient？你如何防止垃圾收集？ –

Azure服務總線，確定OnMessage是否停止處理

回答

相關問題