DeadPoolQueue
Architettura
Flusso
- Worker (DeadPoolQueueWorker)
- Ruolo: Orchestratore del servizio.
- Funzionamento: Esegue un ciclo infinito che richiama periodicamente il Gestore Errori
- Se il gestore segnala un errore critico, il worker attende un intervallo di tempo configurabile (DeadLetterQueueSettings:MinutiAttesaRiesecuzione) prima di riprovare.
- DeadLetterQueueGestore
- Ruolo: Cuore della logica di business.
- Flusso di Esecuzione:
- Recupera l’elenco di Topic e Sottoscrizioni da Azure Service Bus.
- Itera su ogni sottoscrizione.
- Legge i messaggi dalla Dead Letter Queue in modalità PeekLock (senza rimuoverli subito).
- Invia i messaggi a ElasticSearch per l’archiviazione.
- Se l’archiviazione ha avuto successo, completa i messaggi su Service Bus, rimuovendoli dalla coda.
- Implementa un meccanismo di sicurezza (NrMassimoCicliPerCoda) per evitare loop infiniti su code problematiche.
- AccessoDatiDeadLetterQueues
- Tecnologia: Azure.Messaging.ServiceBus.
- Funzionalità :
- Lettura della topologia (Topic/Subscription) tramite ServiceBusAdministrationClient.
- Lettura messaggi DLQ tramite ServiceBusReceiver.
- Supporto per Retry Policy configurabili.
- AccessoDatiElasticSearch
- Tecnologia: Elastic.Clients.Elasticsearch.
- Funzionalità :
- Indicizzazione dei messaggi.
- Supporto per operazioni Bulk per ottimizzare le performance.
- Gestione dinamica dell’indice di destinazione basata sul messaggio.
Entità salvata
Da ogni messaggio letto nelle dead letter queue vengono prelevati i seguenti dati:
public record ElasticMessageDTO(
DateTime DataOraGestione,
string CodiceDiErrore, // DeadLetterMessage.DeadLetterReason
string MessaggioDiErrore, // DeadLetterMessage.DeadLetterErrorDescription
string Sottoscrizione, // DeadLetterMessage.DeadLetterSource
string CorpoMessaggio // DeadLetterMessage.Body
);Il campo CorpoMessaggio è di tipo string e non object? per evitare di avere una infinità di campi salvati negli indici (soprattutto per le entità più complesse).