Refresh Message Cursor (-REFRESH)

Utilisez la commande d’adaptateur Refresh Message Cursor (-REFRESH) pour vous assurer que les messages de priorité plus élevée sont placés en file d’attente avant les messages existants avec une priorité moindre, de sorte que les messages de priorité supérieure puissent déclencher l’exécution Cette commande n'est utilisée que lors de l'utilisation d'une entrée d'événement IBM® MQ avec le moteur de flux. Si les messages d’une priorité plus élevée sont placés dans la file d’attente après les messages d’une priorité inférieure, le comportement par défaut est que les messages de priorité plus élevée ne déclenchent pas les mappes.

-REFRESH [reset_time]

Option: Description
reset_time: Il s’agit d’un entier non négatif définissant le nombre de secondes qui doivent s’écouler avant que le curseur de message ne soit réinitialisé à la tête de la file d’attente.

La commande d’adaptateur Refresh Message Cursor (-REFRESH) réinitialise le curseur de message du programme d’écoute des événements de la file d’attente source en tête de la file d’attente une fois que chaque cycle du programme d’écoute (détection de tous les messages actuellement dans la file d’attente) est terminé. Vous pouvez éventuellement spécifier un argument entier non négatif (reset_time) qui définit le nombre de secondes qui doivent s’écouler avant que le curseur de message ne soit réinitialisé en tête de la file d’attente. Si reset_time est défini sur zéro, le curseur de message sera constamment réinitialisé au début de la file d’attente après chaque événement. Par conséquent, les messages de priorité plus élevée sont traités dès que possible. Toutefois, le repositionnement fréquent du curseur entraînera une dégradation des performances globales.

La commande d'adaptateur Refresh Message Cursor (-REFRESH) n'est requise que lors de l'utilisation d'une entrée d'événement IBM® MQ avec le moteur de flux, et uniquement dans deux situations spécifiques :

Lorsque des messages de priorité supérieure sont placés au début de la file d’attente et ne sont pas reconnus parce que le curseur de message a déjà commencé à se déplacer vers le bas de la file d’attente.
Lorsqu’il existe une possibilité que le curseur de message ignore les messages non validés dans la file d’attente. A titre d’exemple, supposons que deux applications, APP1 et APP2, placent simultanément des messages dans une file d’attente vide et que la séquence d’opérations suivante se produise (une possibilité car APP1 et APP2 sont indépendantes et s’exécutent simultanément) :
T0: APP1 PUT(M1) T1 : APP2 PUT(M2) T2 : APP2 COMMIT(M2) T3 : APP1 COMMIT(M1)

Une fois que T1 a lieu, les deux messages ont déjà été placés dans la file d’attente (avec M1 devant M2). Toutefois, ils ne sont pas reconnus par le curseur de message. Une fois que T2 a lieu, le curseur de message reconnaît le message M2 et il se positionne sur ce message. Après l’exécution de T3, le message M1 est également validé, mais il se trouve maintenant au-delà du curseur de message. Le curseur de message ne pourra jamais reconnaître ce message sauf s’il est repositionné au début de la file d’attente. Utilisez la commande d’adaptateur Refresh Message Cursor (-REFRESH) pour effectuer ce repositionnement.

L’utilisation de la commande d’adaptateur Refresh Message Cursor (-REFRESH) peut dégrader les notifications d’événements et les performances de mappage et ne doit être utilisée que si nécessaire. L’adaptateur doit veiller à ne pas déclencher la mappe plus d’une fois pour le même message d’entrée. Pour ce faire, l’adaptateur gère une liste des messages qui ont déjà été vus par le curseur. Chaque fois que le curseur est repositionné au début de la file d’attente, chaque message détecté par le curseur dans la file d’attente est comparé à tous les messages de cette liste. Dans les situations où ce message ne figure pas dans la liste des adaptateurs, il est considéré comme étant un nouveau message à utiliser pour la notification d’événement. Dans le cadre de ce processus, ce nouveau message sera ajouté à la liste des adaptateurs. Pour s’assurer que cette liste n’augmente pas indéfiniment, il existe deux limitations importantes pour les cartes d'entrée qui utilisent la commande d’adaptateur -REFRESH :

L’option de restauration du paramètre sur Sur échec ne doit pas être utilisée.
L’option Conserver du paramètre OnSuccess ne doit pas non plus être utilisée.

Si l'une de ces deux options est spécifiée, l'exécution du moteur de flux pendant une longue période avec un grand nombre de messages en cours de traitement peut entraîner une utilisation excessive de la mémoire et ralentir considérablement le temps de traitement, ce qui peut entraîner l'arrêt du système.

Cela est dû au fait que les messages une fois vus par le curseur sont ajoutés à la liste interne et, tant qu’ils ne sont pas supprimés de la file d’attente source, ils ne sont pas non plus supprimés de la liste de l’adaptateur interne afin qu’ils ne soient pas traités plus d’une fois. Les messages ne sont libérés de la liste interne qu’une fois qu’ils ont été supprimés de la file d’attente source.

Dans les situations où il est nécessaire d’utiliser la commande d’adaptateur Refresh Message Cursor (-REFRESH) et de conserver les messages pour la mappe en échec, il est recommandé d’utiliser la commande d’adaptateur Error Queue Name (-EQN) en combinaison avec la commande d'adaptateur -REFRESH pour la carte d'entrée. Dans ce cas, le paramètre Source > Transaction > OnSuccess doit être Supprimer et le paramètre Source > transaction > OnFailure doit être Restaurer. Les messages relatifs à l’échec de la mappe sont placés dans la file d’attente des erreurs et supprimés de la file d’attente source. Par conséquent, les messages sont conservés (dans la file d’attente des erreurs) et aucune fuite de mémoire ne se produira car il sera possible de supprimer des messages de la liste de l’adaptateur interne lors de leur déplacement dans la file d’attente des erreurs. Notez toutefois que si, pour une raison quelconque, les messages ne peuvent pas être stockés dans la file d’attente des erreurs (par exemple, si l’option PUT est désactivée pour la file d’attente des erreurs), les messages resteront dans la file d’attente d'entrées et dans la liste de l’adaptateur interne, ce qui entraîne une fuite de mémoire possible.