Archiviazione della coda Azure che non invia messaggio di coda
-
21-12-2019 - |
Domanda
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?
Soluzione 2
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.
Altri suggerimenti
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.