Abbiamo già detto che esiste solo oneway-messaging e che exactly-once delivery è una chimera, per continuare la mia carrellata di buoni motivi per non impelagarsi in un sistema distribuito oggi vorrei introdurvi al magico mondo delle poison queue.

Quando un messaggio viene inviato possono succedere le seguenti cose:

• L’infrastruttura non riesce a consegnarlo alla coda di destinazione
• Il messaggio arriva alla coda di destinazione malformed
• Il destinatario riceve il messaggio ma fallisce nel processarlo

Come più volte ho ribadito in un sistema basato su messaggi la perdita di un messaggio porta all’inevitabile corruzione dei dati, ergo perdere un messaggio è cosa quantomeno poco simpatica.

Nei primi due casi di cui sopra l’infrastruttura di solito ci viene in aiuto con il concetto (quasi sempre) built-in di poison queue. Quello che succede è che è possibile definire una coda da usarsi come parcheggio per i messaggi che non possono essere consegnati o che sono malformed.

Il terzo caso è un po’ al limite, tecnicamente il messaggio è buono ed è stato pure consegnato, ma il destinatario fallisce nel processarlo, per colpa, ad esempio, di un bug viene sollevata un’eccezione. Ne consegue che il messaggio resta in coda, in testa alla coda, con il rischio quindi che venga riprocessato, e riprocessato, e riprocessato, e riprocessato, all’infinto. Causando una sorta di denial of service al destinatario per colpa del destinatario. In base all’infrastruttura anche un messaggio malformed potrebbe portare allo stesso identico scenario.

In questo terzo caso avete quindi bisogno che il vostro codice sia in grado di dire all’infrastruttura: basta, non farmelo più vedere e spostalo in una poison queue.

Ovviamente ci ritroviamo in uno scenario interessante:

• Il mittente ha mandato un messaggio, e come abbiamo detto non ha alcuna possibilità di sapere come stanno le cose
• Il destinatario non l’ha mai ricevuto o l’ha ricevuto e ha fallito nel processarlo
• Il messaggio sta bello bello, buono buono, in una poison queue

Abbiamo quindi bisogno di fare monitoraggio delle poison queue, di capire perché i messaggi sono finiti li, e infine ove servisse di riprovare a consegnare i messaggi.