La DLQ d'un Queue Manager doit-elle *obligatoirement* être une file d'attente locale sur le QM ?

Question

Nous essayons de consolider les DLQ de notre entreprise en un seul Q (un Enterprise_DLQ si vous voulez...). Nous avons un mélange de QM sur diverses plates-formes - Mainframe, diverses saveurs Unix - Linux, AIX, Solaris etc., Windows, AS/400..... L'idée était de configurer le DLQ sur le QM (définir l'attribut DEADQ sur le QM) à celui de ENTERPRISE_DLQ qui est un Cluster Q. Tous les QM de l'Entreprise sont membres du Cluster. Cependant, cette approche ne semble pas fonctionner lorsque nous l'avons testée. J'ai testé cela en mettant en place un Cluster simple avec 4 QMs. Sur l'un des QM, j'ai défini un QRemote vers un QM inexistant et un Q inexistant, mais un xmitq valide et configuré le requsite SDR chl entre les QM comme suit :

QM_FR - Full_Repos QM1, QM2, QM3 - membres du cluster

QM_FR héberge ENTERPRISE_DLQ qui est annoncé au Cluster.

Sur QM3, configurez les éléments suivants : QM3.QM1 - sdr vers QM1, ql(QM1) avec utilisation xmitq, qr(qr.not_exist) rqmname(not_exist) rname(not_exist) xmitq(qm1), configurer QM1 pour déclencher le démarrage de QM3.QM1 quand un message arrive sur QM1.

Sur QM1 : QM3.QM1 - rcvr chl, ql(local_dlq), ql(qa.enterise_dlq), qr(qr.enterprise.dlq)

Test 1 : Définir deadq sur QM1 à ENTERPRISE_DLQ, écrire un msg à QR.NOT_EXIST sur QM3. Résultat : Le msg reste sur QM1, QM3.QM1 est RETRYING, les logs d'erreur de QM1 se plaignent de ne pas pouvoir MQOPEN le Q - ENTERPRISE_DLQ ! !!

ql(qm1) curdepth(1)

Test 2 : Régler deadq sur QM1 à qr.enterprise.dlq, écrire un msg à QR.NOT_EXIST sur QM3 Résultat : Le msg reste sur QM1, QM3.QM1 est RETRYING, les logs d'erreur de QM1 se plaignent de ne pas pouvoir MQOPEN le Q - qr.enterprise.dlq (tout en majuscules) ! !!

ql(qm1) curdepth(2)

Test 3 : Définir deadq sur QM1 à qa.enterise_dlq, écrire un msg à QR.NOT_EXIST sur QM3 Résultat : Le msg reste sur QM1, QM3.QM1 est RETRYING, les journaux d'erreurs de QM1 se plaignent de ne pas pouvoir MQOPEN le Q - qa.enterise_dlq (tout en majuscules) ! !!

ql(qm1) curdepth(3)

Test 4 : Régler deadq sur QM1 à local_dlq, écrire un msg à QR.NOT_EXIST sur QM3 Résultat : Le message reste sur QM1, QM3.QM1 est RUNNING, tous les messages sur QM3 ql(QM1) arrivent à local_dlq sur QM3.

ql(qm1) curdepth(0)

Maintenant la question : On dirait que le DLQ sur un QM doit soit une file d'attente locale. Cette conclusion est-elle correcte ? Si ce n'est pas le cas, comment puis-je faire en sorte que tous les messages des DLQs aillent à un seul Q - Enterprise_DLQ ci-dessus ?

Une solution évidente est de définir un déclencheur sur local_dlq sur QM3 (et de faire de même sur les autres QMs) qui lira le message et l'écrira dans le Cluster Q - ENTERPRISE_DLQ. Mais cela implique des parties mobiles supplémentaires - déclencheur, moniteur de déclenchement sur chaque QM. Il est plus souhaitable de pouvoir configurer un Cluster Q/QRemote/QAlias pour être un DLQ sur le QM. Réflexions/idées ? ??

Merci -Ravi

Answer 1

Selon la documentation aquí :

Une file d'attente de type "dead-letter" n'a pas d'exigences particulières sauf que :

• Il doit s'agir d'une file d'attente locale
• Son attribut MAXMSGL (longueur maximale du message) doit permettre à la file d'attente d'accueillir les plus gros messages que le gestionnaire de la file d'attente a
  à gérer plus la taille de l'en-tête de la lettre morte (MQDLH).

La DLQ permet à un QMgr de traiter les messages qu'un canal n'a pas pu délivrer. Si la DLQ n'était pas locale, la gestion des erreurs pour les canaux serait elle-même dépendante des canaux. Cela présenterait une sorte de défaut de conception architecturale.

La façon prescrite de faire ce que vous voulez est de déclencher un travail pour transmettre les messages à la file d'attente distante. Ainsi, chaque fois qu'un message arrive dans la DLQ, le travail déclenché se déclenche et transfère les messages. Si vous ne voulez pas écrire un tel programme, vous pouvez facilement utiliser un peu de code shell ou Perl et le programme Q de SupportPac MA01 . Il serait souhaitable que les canaux utilisés pour envoyer ces messages depuis le QMgr soient configurés pour ne pas utiliser la DLQ. Idéalement, ces canaux devraient se trouver dans un cluster dédié afin que le trafic DLQ ne se mélange pas au trafic des applications.

Sachez également que l'une des fonctions du DLQ est de faire sortir les messages du XMitQ si une erreur de conversion empêche leur envoi. Leur transfert vers un emplacement central aurait pour effet de les remettre sur le XMitQ du cluster. De même, si la destination est pleine, ces messages se retrouveront également sur le XMitQ du cluster du qMgr expéditeur. S'ils s'y accumulent en nombre suffisant, un XMitQ de cluster plein empêcherait tous les canaux de cluster de fonctionner. Dans ce cas, vous auriez besoin d'une sorte d'outil pour vous permettre de supprimer ou de déplacer sélectivement les messages hors du cluster XMitQ, ce qui serait un peu difficile.

En gardant tout cela à l'esprit, il semblerait que cette exigence présente plus de défis qu'elle n'en résout. Recommandation : la gestion des erreurs pour les canaux est mieux gérée sans utilisation ultérieure des canaux - c'est-à-dire localement.