[AIX Solaris HP-UX Linux Windows][IBM i]

Ordre strict des messages en utilisant des ports d'écoute non-ASF

L'ordre strict des messages peut être obtenu lors du déploiement des applications de bean géré par message dans le fournisseur de messagerie IBM MQ lorsque aucune fonction spéciale n'est codée dans l'application pour gérer les messages qui n'arrivent pas dans l'ordre.

Les ports d'écoute sont stabilisés à partir de la version 7 et des versions ultérieures de WebSphere Application Server. Pour plus d'informations, lisez l'article sur les fonctions stabilisées. Vous devez vous préparer à faire migrer vos configurations de déploiement de bean géré par message WebSphere MQ depuis l'utilisation des ports d'écoute vers l'utilisation des spécifications d'activation. [AIX Solaris HP-UX Linux Windows][IBM i]Pour plus d'informations sur la configuration des spécifications d'activation du mode non-ASF, voir Configuration de spécifications d'activation du mode non-ASF. Toutefois, ne commencez pas cette migration si vous pensez que l'application a encore besoin d'utiliser des serveurs d'applications antérieurs à WebSphere Application Server Version 7. Par exemple, si vous disposez d'un cluster de serveurs d'applications dont certains membres sont à la version 6.1 et d'autres à une version ultérieure, vous ne devez pas migrer les applications de ce cluster pour qu'elles utilisent les spécifications d'activation avant d'avoir migré tous les serveurs d'applications du cluster vers la version ultérieure.

Ce scénario repose sur les hypothèses suivantes :
  • L'application de bean géré par message (MDB) est transactionnelle.
  • Le seuil d'annulation (BOTHRESH) dans la file d'attente IBM MQ a la valeur 0.

Configuration WebSphere Application Server pour la distribution ordonnée

  • Le mode non-ASF doit être activé en définissant une valeur de délai d'attente différente de zéro pour la propriété personnalisée des services d'écoute des messages NON.ASF.RECEIVE.TIMEOUT IBM MQ.
  • Le paramètre Maximum sessions du port d'écoute doit avoir la valeur 1.
  • Un port d'écoute non-ASF dont le nombre maximal de sessions est égal à 1 a une seule unité d'exécution exécutée dans le serveur d'applications qui extrait les messages. Lorsqu'un message arrive, l'unité d'exécution le distribue immédiatement à MDB.
  • Le gestionnaire de files d'attente considère cette unité d'exécution comme une application d'extraction de messages et les messages sont donc traités séquentiellement.

Les messages peuvent être distribués dans le désordre avec ce déploiement lors d'une récupération de transaction.

Pour qu'un tel scénario se produise, un ensemble d'événements doivent survenir dans un ordre donné, ce qui n'est pas fréquent. Toutefois, si la distribution des messages dans un certain ordre est d'une importance primordiale pour la bonne exécution de votre application, vous devez la prendre en compte.

  • Avec cette option de déploiement, la procédure de récupération après l'échec de l'un des composants suivants peut entraîner la distribution des messages dans un ordre incorrect :
    • Le serveur d'applications hébergeant le bean géré par message
    • Le gestionnaire de files d'attente IBM MQ
    • Un réseau connectant le serveur d'applications et le gestionnaire de files d'attente
  • Si l'un de ces composants échoue au milieu de la validation en deux phases d'une transaction liée à un bean géré par message, le gestionnaire de transactions du serveur d'applications établit de nouveau la connexion au gestionnaire de files d'attente afin de résoudre la transaction une fois que le composant redevient disponible.
  • Cette procédure de récupération est asynchrone et la distribution des nouveaux messages au bean géré par message peut reprendre avant qu'elle se termine. Si le résultat de la récupération de la transaction est l'annulation de celle-ci, le message est renvoyé à la file d'attente WebSphere MQ et redistribuée à l'application, éventuellement après d'autres messages plus récents.

Considérations pour un déploiement en cluster

Lorsque vous utilisez des ports d'écoute non-ASF, vous pouvez affecter à l'option de partage par défaut (DEFSOPT) dans la file d'attente la valeur exclusive. Si vous choisissez cette option lorsque vous exécutez un déploiement en cluster d'une application, l'un des membres du cluster ne démarre pas ses ports d'écoute. Les membres du cluster génèrent une exception 2042MORC_OBJECT_IN_USE dans un message WMSG0057E.

Lorsque cette exception est émise, vous pouvez établir la reprise en ligne automatique pour l'application en définissant la propriété personnalisées des services d'écoute des messages dans WebSphere Application Server :

MAX.RECOVERY.RETRIES
Définissez une valeur MAX.RECOVERY.RETRIES élevée dans les services d'écoute des messages de tous les serveurs du cluster. La valeur maximale de MAX.RECOVERY.RETRIES est 2147483647.
La propriété personnalisée des services d'écoute des messages MAX.RECOVERY.RETRIES doit être combinée à une propriété personnalisée des services d'écoute des messages MAX.RECOVERY.INTERVAL. Le délai maximal de nouvelle tentative d'un port d'écoute sans être arrêté et redémarré manuellement est égal à la multiplication de 2147483647 par la valeur définie dans MAX.RECOVERY.INTERVAL. Dans cette configuration, chaque membre du cluster tente en continu de démarrer son port d'écoute jusqu'à ce que le membre actif du cluster s'arrête que le gestionnaire de files d'attente l'autorise à se connecter en tant que consommateur exclusif .

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmm_wmq_smo_nonasflp
Nom du fichier : cmm_wmq_smo_nonasflp.html