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 WebSphere 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]](../images/dist.gif)
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 WebSphere MQ a la valeur 0.
- Vous utilisez WebSphere MQ Version 6.0.
Configuration WebSphere
Application Server pour la distribution ordonnée
- Si vous utilisez des ports d'écoute, le nombre maximal de sessions sur les ports d'écoute dans WebSphere
Application Server doit être égal à 1.
- Si vous utilisez des spécifications d'activation, le nombre maximal de sessions de serveur dans les spécifications d'activation dans WebSphere
Application Server doit égal à 1.
Informations importantes sur cette configuration
Cas dans lesquels les messages arrivent dans le désordre
Les messages peuvent arriver dans le désordre avec ce déploiement dans les cas suivants :
- Lors de la récupération d'une transaction, les messages risquent
d'être distribués dans un ordre incorrect.
Remarque : 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 WebSphere 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.
- Lorsqu'une transaction a été annulée, le prochain message disponible
sur la file d'attente doit être distribué avant la redistribution du message annulé.
- Dans le cas d'un port d'écoute ASF, si le Nombre maximal de tentatives
est défini sur zéro, le port d'écoute est arrêté en cas d'annulation et
les messages ne risquent donc pas d'être distribués dans un ordre incorrect. Toutefois, il est nécessaire de redémarrer
manuellement le port d'écoute.
- Pour une spécification d'activation, lorsque vous sélectionnez Arrêter le noeud final
en cas d'échec de distribution des messages et que vous définissez le Nombre
d'échecs de distribution séquentiels avant la mise en suspens du noeud final sur 0,
le noeud final du message est mis en suspens en cas d'annulation et les messages ne risquent donc
pas d'être distribués dans le désordre. Toutefois, il est nécessaire de redémarrer le noeud
final du bean géré par message manuellement. Pour plus d'informations, voir le centre de documentation WebSphere MQ.
- Au cours du fonctionnement normal, lorsque plusieurs unités d'exécution envoient des messages à la destination (pour différences séquences) en utilisant des transactions :
- Ce comportement est dû au fonctionnement du curseur d'exploration WebSphere MQ.
- Lorsq'un message est validé dans une file d'attente WebSphere MQ et que la validation d'un autre message envoyé à la destination est annulée (dans une transaction pas encore terminée), le curseur d'exploration entre dans le nouveau message dans la file d'attente et ne renvoie pas automatiquement l'ancien message lorsqu'il est finalement validé. Dans ce cas, les messages peuvent apparaître dans la file d'attente à la suite du curseur d'exploration.
- Dans ce cas, les nouveaux messages dans une séquence peuvent être distribués au bean MDB avant que le fournisseur de messagerie WebSphere MQ ne relise la file d'attente et détecte le message qui est apparu derrière le curseur d'exploration.
- Si l'attribut de séquence de distribution de messages (MSGDLYSEQ) de la file d'attente WebSphere MQ contrôlée par une spécification d'application ou un port d'écoute ASF a la valeur priority, l'ordre des messages peut échouer pour les raisons suivantes :
- Les messages de priorité plus basse peuvent être distribués avant les messages ayant une priorité plus élevée lorsque des messages à plusieurs priorité sont envoyés à une file d'attente. Ce comportement est dû au fonctionnement du curseur d'exploration WebSphere MQ. Le curseur d'exploration parcourt tous les messages disponibles ayant la priorité la plus élevée, puis il parcourt les messages ayant une priorité plus basse. Si des messages à haute priorité arrivent lorsque le curseur d'exploration parcourt les messages à faible priorité, les messages à haute priorité peuvent ne pas être distribués avant distribution de tous les messages à faible priorité dans la file d'attente.
- Les ports d'écoute ASF ou les spécifications d'activation qui parcourent les files d'attente dont le paramètre de séquence de distribution des messages a la valeur FIFO ne détecte pas le problème, car WebSphere MQ classe les messages dans la file d'attente selon leur ordre d'arrivée et non pas en fonction de leur priorité.
Considérations pour un déploiement en cluster
- Vous pouvez activer le bean MDB sur un membre du cluster uniquement, car le serveur d'applications ne dispose pas d'une fonction qui peut gérer cette activation automatiquement.
- Vous pouvez définir l'état de démarrage des ports d'écoute sur Arrêté indépendamment de l'état de démarrage d'une application.
- Vous pouvez démarrer et arrêter manuellement les applications, les ports d'écoute ASF et les noeuds finaux de message avec des interfaces MBean en utilisant le scriptage wsadmin ou les interfaces
com.ibm.websphere.management.AdminClient depuis le code Java™.