Archiviazione della coda Azure che non invia messaggio di coda

Question

Sto usando uno spazio di archiviazione della coda Azure per inviare e-mail.Le e-mail sono memorizzate nella memorizzazione della coda e la coda invia 20 e-mail alla volta.

//Checks for messages inn the queue
foreach (CloudQueueMessage msgin sendEmailQueue.GetMessages(20, TimeSpan.FromSeconds(50)))
   {
        ProcessQueueMessage(msg);

   }

.

Il problema che sto avendo è che quando un'e-mail viene aggiunta alla coda con dettagli SMTP errati (cioè password errata), il messaggio rimane in coda in quanto non riesce a inviare e impedisce ad altri messaggi in coda dall'invio. .

private void ProcessQueueMessage(CloudQueueMessage msg)
{
  try
  {
    //We try to send an email
    SendEmail(emailRowInMessageTable, htmlMessageBodyRef, textMessageBodyRef);

  } catch (SmtpException e)
  {
    string err = e.Message;

    //When an error occurs we check to see if the message failed to send certain no. of      
      times
    if (msg.DequeueCount > 10)
    {
      //We delete the message from queue
      sendEmailQueue.DeleteMessage(msg);

      return;
    } else
    {
      //delete from top of queue
      sendEmailQueue.DeleteMessage(msg);

      //insert into end of queue
      sendEmailQueue.AddMessage(msg);

      return;
    }
  }
 }

.

La soluzione che ho provato era di cancellare il messaggio dalla coda se si è verificato un errore e aggiungerlo Torna alla fine della coda con il risultato delle e-mail corrette inviate.Ma cancellazione e aggiunta Il messaggio di ritorno nella coda ripristina la sua proprietà dequeue che non è l'ideale Dal momento che sto usando la proprietà Dequeue per assicurarmi che un messaggio non sia in coda per sempre.

Quale sarebbe la soluzione migliore in questa situazione?

Answer 1

La soluzione era utilizzare diverse code per diversi server SMTP ed eseguire tutto da un ruolo lavoratore utilizzando più fili.

Utilizzato il framework qui: http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/running-multiple-threads-on-windows.html per eseguire più fili all'interno di un singolo ruolo di lavoratore.

Answer 2

Non devi davvero cancellare il messaggio e aggiungerlo.Una volta che il periodo visibility timeout del messaggio (50 secondi nel tuo caso) è scaduto, verrà automaticamente riportato in coda.In questo modo, la tua logica DequeueCount funzionerebbe anche come lo stesso messaggio è di nuovo dequeed ed enquequed.

Si prega di notare che le code di Windows Azure sono il miglior sforzo FIFO ... quindi non è sempre necessario e che i messaggi saranno selezionati sulla base del tempo in cui sono stati aggiunti.Potresti fare alcune cose:

.
• Riduci il numero di tentativi (attualmente ne hai 10, puoi ridurlo a 5) o
• Controllare l'eccezione effettiva.Se il processo non è riuscito a causa di credenziali errate, fallirà la prossima volta e la prossima volta dopo.Non c'è punto di riprovare quel messaggio.Potresti semplicemente spostare quel messaggio in una coda veleno in modo da poter ispezionare il messaggio più tardi.