Gestione degli errori da parte di MQInput

Il nodo MQInput intraprende le seguenti azioni quando gestisce gli errori con messaggi permanenti e transazionali. Gli errori che si presentano con messaggi non transazionali sono gestiti come descritto in Gestione degli errori nel nodo di input.

Tale azione è riepilogata nella seguente tabella:

Evento di errore Terminale Failure connesso Terminale Failure non connesso Terminale Catch connesso Terminale Catch non connesso
Il nodo individua un errore interno Il flusso connesso al terminale Failure gestisce l'errore Messaggio inserito in una coda alternativa; il nodo ripete l'operazione se l'inserimento non ha esito positivo Non applicabile Non applicabile
Il nodo trasmette il messaggio al terminale out, l'eccezione si verifica nel flusso out Non applicabile Non applicabile Il flusso connesso al terminale Catch gestisce l'errore Il nodo ripete l'operazione
Il nodo trasmette il messaggio a un terminale Catch, l'eccezione si verifica nel flusso connesso al terminale Catch Errore registrato, messaggio sottoposto a rollback Errore registrato, messaggio sottoposto a rollback Non applicabile Non applicabile
Il nodo trasmette il messaggio a un terminale Failure, l'eccezione si verifica nel flusso connesso al terminale Failure Non applicabile Non applicabile Il nodo ripete l'operazione Il nodo ripete l'operazione

Tentativi successivi di elaborazione

Il nodo esegue un nuovo tentativo di elaborazione quando il messaggio è sottoposto a rollback nella coda di input. Esso controlla se il messaggio è stato ripristinato allo stato precedente e, in tal caso, se il conteggio di ripristino allo stato precedente abbia raggiunto (uguagliato) la soglia di ripristino allo stato precedente. Il conteggio di ripristino allo stato precedente per ogni messaggio è conservato da WebSphere MQ in MQMD.

Si specifica l'attributo della soglia di ripristino allo stato precedente BOTHRESH (o si accetta un valore predefinito 0) quando si crea la coda. Se si accetta il valore predefinito di 0, il nodo lo aumenta a 1. Il nodo imposta il valore su 1 anche se non può individuare il valore corrente. Questo significa che se un messaggio non è stato mai ripristinato allo stato precedente, viene ripristinato allo stato precedente e ripetuto almeno una volta.

  1. Se il nodo ha trasmesso un messaggio al terminale out molte volte in seguito a ripetuti tentativi non riusciti nel flusso out e il numero dei tentativi ha raggiunto il limite della soglia di ripristino allo stato precedente, esso prova a trasmettere il messaggio attraverso il terminale Failure, se connesso. Se il terminale Failure non è connesso, il nodo prova a inserire il messaggio in un'altra coda.

    Se si verifica un errore dopo il terminale Failure, si effettuano ulteriori tentativi fino a quando il campo del conteggio di ripristino allo stato precedente in MQMD non raggiunga due volte la soglia di ripristino allo stato precedente impostata per la coda di input. Quando viene raggiunto questo limite il nodo prova a inserire il messaggio in un'altra coda.

  2. Se la soglia di ripristino allo stato precedente non è stata raggiunta, il nodo richiama nuovamente il messaggio dalla coda. Se questa operazione non ha esito positivo, il problema viene gestito come un errore interno (descritto sopra). Se ha esito positivo, il nodo trasmette il messaggio al flusso out.
  3. Se la soglia di ripristino allo stato precedente è stata raggiunta:
    • Se il terminale Failure è stato connesso, il nodo trasmette il messaggio a tale terminale. E' necessario gestire l'errore sul flusso connesso al terminale Failure.
    • Se il terminale Failure non è connesso, il nodo prova ad inserire il messaggio in una coda disponibile, in ordine di preferenza:
      1. Il messaggio è inserito nella coda di ripristino allo stato precedente della coda di input (attributo coda BOQNAME), se definita.
      2. Se la coda di ripristino allo stato precedente non è definita o non è possibile identificarla da parte del nodo, il messaggio viene inserito nella DLQ (dead letter queue/coda di messaggi non recapitati), se definita. (Se il gestore code del broker è stato definito dal comando mqsicreatebroker, è stata definita una DLQ con un nome predefinito SYSTEM.DEAD.LETTER.QUEUE, abilitata per questo gestore code.)
      3. Se il messaggio non può essere inserito in nessuna di queste code perché è presente un errore MQPUT (incluso "la coda non esiste") o perché le code non possono essere identificate dal nodo, è impossibile gestirlo in modo sicuro senza rischi di perdita di dati.

        Il messaggio non può essere eliminato, quindi il flusso di messaggi continua a provare l'operazione di ripristino allo stato precedente del messaggio. Esso registra la situazione di errore scrivendo gli errori nella registrazione errori locale. Una seconda indicazione di questo errore è il continuo incremento del BackoutCount del messaggio nella coda di input.

        Se questa situazione si è verificata poiché non esiste né l'una né l'altra coda, è possibile definire una delle code di ripristino allo stato precedente menzionate sopra. Se la condizione che impedisce al messaggio di essere elaborato è stata eliminata, è possibile incrementare temporaneamente il valore dell'attributo BOTHRESH. In questo modo si forza il messaggio in una normale elaborazione.

  4. Se la soglia di ripristino allo stato precedente viene raggiunta o superata due volte, il nodo prova ad inserire il messaggio su una coda disponibile, in ordine di preferenza, come descritto nella fase precedente.

Gestione degli errori del gruppo di messaggi

WebSphere MQ supporta i gruppi di messaggi. E' possibile specificare che un messaggio appartiene a un gruppo e che quindi la sua elaborazione è completata in riferimento agli altri messaggi presenti nel gruppo (cioè, i messaggi vengono tutti sottoposti a commit o vengono tutti sottoposti al rollback). Quando si inviano messaggi raggruppati a un broker, tale condizione è supportata se il flusso di messaggi è stato configurato correttamente e non si verificano errori durante l'elaborazione dei messaggi del gruppo.

Per configurare il flusso di messaggi per gestire i messaggi raggruppati correttamente, seguire le azioni descritte nel Nodo MQInput. Tuttavia, la corretta elaborazione del gruppo di messaggi non è garantita se si verifica un errore mentre uno dei messaggi viene elaborato.

Se il nodo MQInput è stato configurato come descritto, in circostanze normali tutti i messaggi nel gruppo vengono elaborati in una singolo unità di lavoro che viene sottoposta a commit quando l'ultimo messaggio del gruppo è stato elaborato con esito positivo. Tuttavia, se si verifica un errore prima che l'ultimo messaggio del gruppo venga elaborato, l'unità di lavoro che include i messaggi fino al messaggio che ha generato l'errore, compreso tale messaggio, è soggetta alla gestione degli errori definita dalle regole qui documentate, che potrebbe risultare nel ripristino allo stato precedente dell'unità di lavoro.

Comunque, tutti i messaggi rimanenti all'interno del gruppo possono essere letti ed elaborati con esito positivo dal flusso di messaggi e quindi gestiti e sottoposti a commit in una nuova unità di lavoro. Un commit viene avviato quando viene elaborato l'ultimo messaggio. Quindi, se si verifica un errore all'interno del gruppo, ma non nel primo o nell'ultimo messaggio, è possibile che una parte del gruppo sia ripristinata allo stato precedente e un'altra parte sia sottoposta a commit.

Se i requisiti di elaborazione del messaggio richiedono che questa situazione venga gestita in un modo particolare, è necessario fornire una gestione degli errori aggiuntiva per gestire gli errori all'interno dei gruppi di messaggi. Ad esempio, si potrebbe registrare l'errore di un gruppo di messaggi all'interno di un database e includere un controllo sul database quando si richiama ogni messaggio, forzando un rollback se il gruppo attuale ha già rilevato un errore. Questo garantirebbe che tutto il gruppo di messaggi sia ripristinato allo stato precedente e non elaborato a meno che non abbiano tutti esito positivo.

Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac00414_