Azure Service Bus, determinare se OnMessage interrompe l'elaborazione

Question

Utilizzo di Azure ServiceBus e della chiamata OnMessage Sto cercando un modo per determinare se la pompa di eventi OnMessage interrompe la lettura dalla coda.

La nostra connessione a OnMessage è configurato come di seguito:

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); 
} 

Il problema che stiamo incontrando è dopo un periodo di tempo senza messaggi di essere in coda i nuovi messaggi in coda non essere raccolto dall'evento OnMessage pompa fino al riavvio dell'applicazione.

Mi rendo conto che ci sono modi per farlo utilizzando i ruoli di lavoro, tuttavia per scopi di monitoraggio e gestione, abbiamo deciso di implementarlo nell'applicazione Avvio di un'app Web.

Answer 1

Quindi, dopo una chiamata con il team di supporto di Azure di Microsoft, non c'è un evento da intercettare quando si verificano errori OnMessage o OnMessageAsync. Poiché non stanno bloccando le chiamate, avvia il pump degli eventi e ritorna al thread in esecuzione, creando una sfida per determinare se OnMessage * sta facendo il suo lavoro.

Suggerimenti da Microsoft sono stati:

• Creare la tua implementazione della classe QueueClientBase che espone l'OnClose, sui metodi * che si poteva gestire. Tuttavia, nel fare questo devi fare da solo la gestione della busta del messaggio.
• Utilizzare OnRicevere in un ciclo di thread separato, che è possibile intercettare gli errori e riprovare immediatamente.

Tuttavia, ho esplorato alcune prove di proiettile contro OnMessage e scoperto alcune cose che hanno alleviato le mie paure.

• OnMessage è incredibilmente tollerante ai guasti
  • ho uplugged il cavo ethernet dal mio computer portatile con wireless spento, questo ha rotto la connessione del OnMessage alla coda Service Bus. Dopo aver atteso 10 minuti, ho ricollegato il cavo ethernet e OnMessage ha immediatamente iniziato a elaborare gli elementi in coda.
• Il messaggio è sorprendentemente abbastanza stabile. È stato eseguito all'interno dell'app Global.asax.cs, per abbreviare, per giorni e giorni, con un Factory IdleTimeout impostato su 24 ore senza riavviare l'applicazione Web per 72 ore.

Tutto sommato, ho intenzione di continuare a utilizzare OnMessage/OnMessageAsync per ora e tenerlo d'occhio. Aggiornerò questo se vedrò problemi che cambiano la mia opinione su OnMessage.

A parte - Assicurarsi che si stia utilizzando OnMessage per l'ascolto permanente in un sito Web di Azure che si imposta l'opzione di configurazione "Sempre attivo" su "On". Altrimenti, a meno che una richiesta Web non venga inserita, OnMessage verrà eliminato e i messaggi non verranno più elaborati fino a quando l'applicazione Web non verrà risvegliata da una richiesta HTTP.