Mode de traitement des messages en mode non ASF

En mode non ASF, les unités d'exécution sont actives dès que le démarrage du port du programme d'écoute. Le nombre d'unités d'exécution actives est déterminé par la valeur indiquée pour Maximum Sessions. Le nombre d'unités d'exécution indiqué dans Maximum Sessions est actif, quel que soit le nombre de messages pouvant être traités. Chaque unité d'exécution active est une connexion réseau physique individuelle.

Si vous utilisez la version 7.0 ou ultérieure d' IBM MQ comme fournisseur de messagerie, il est possible d'avoir jusqu'à dix threads partageant une seule connexion réseau physique.

Pour WebSphere® Application Server version 7 et ultérieure, les ports d'écoute sont stabilisés. Pour plus d'informations, consultez la rubrique sur les fonctions stabilisées. Préparez-vous à 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. Toutefois, ne commencez pas cette migration tant que vous n'êtes pas certain que l'application n'a pas à fonctionner sur des serveurs d'applications antérieurs à WebSphere Application Server version 7. Par exemple, si vous disposez d'un cluster de serveurs d'applications avec des membres de la version 6.1 et d'une version ultérieure, vous ne devez pas migrer les applications de ce cluster pour utiliser les spécifications d'activation tant que vous n'avez pas migré tous les serveurs d'applications du cluster vers la version ultérieure.

Traitement des messages en mode non ASF

Pour activer le mode non ASF, indiquez une valeur différente de zéro pour la propriété personnalisée NON.ASF.RECEIVE.TIMEOUT du service du programme d'écoute des messages. La propriété NON.ASF.RECEIVE.TIMEOUT joue le rôle d'un commutateur qui désactive le mode ASF. Elle correspond également à une valeur de délai pour la méthode receive().

Remarque: Les propriétés personnalisées suivantes du service d'écoute des messages ne fonctionnent pas en mode non ASF:

SERVER.SESSION.POOL.REAP
SERVER.SESSION.POOL.UNUSED.TIMEOUT
SERVER.SESSION.POOL.UNUSED.TIMEOUT.Ipaname

Le diagramme suivant montre comment le traitement des messages s'effectue entre WebSphere Application Server et IBM MQ en mode non ASF :

Comme présenté dans le diagramme, lorsque le service d'écoute de messages est en mode non ASF, les messages sont traités de la manière suivante :

Une fois le port d'écoute démarré, ce dernier obtient une unité d'exécution provenant du pool d'unités d'exécution correspondant au service d'écoute des messages.
Le port d'écoute ouvre une connexion vers le gestionnaire de file d'attente IBM MQ sur le thread et crée un consommateur de messages JMS. Ce dernier écoute sur la destination JMS sur laquelle le port d'écoute écoute également.
Le port d'écoute crée une transaction afin de gérer le traitement des messages.
L'unité d'exécution appelle la méthode receive() sur le destinataire de message afin d'écouter les messages au niveau de la destination. Si la méthode receive() ne détecte aucun message pendant la période définie pour NON.ASF.RECEIVE.TIMEOUT, le serveur d'applications annule la transaction active et en démarre une nouvelle. L'unité d'exécution commence ensuite à appeler à nouveau la méthode receive().
Lorsque le destinataire détecte un message, il vérifie si le message est approprié pour le bean MDB qui utilise le port d'écoute.
Si le message est approprié, la méthode receive() le retire de la destination et l'envoie à l'unité d'exécution.
L'unité d'exécution appelle la méthode onMessage() du bean MDB sur le destinataire du message puis le message est traité.
Si la traitement du message abouti, la transaction est validée. Dans le cas contraire, elle est annulée.
Une nouvelle transaction est démarré et le destinataire du message appelle la méthode receive() afin de surveiller les nouveaux messages.

Le nombre d'unités d'exécution qu'un bean géré par message peut traiter simultanément est déterminé par la valeur de la propriété Maximum Sessions pour le port d'écoute. Si vous affectez à Maximum Sessions la valeur par défaut 1, cela signifie que le bean géré par message ne peut traiter qu'un seul message à la fois. Si vous souhaitez traiter plusieurs messages simultanément, vous pouvez le faire en mode ASF en définissant Maximum Sessions sur une valeur supérieure à 1. Par exemple, si vous définissez Maximum Sessions sur 2, les messages sont traités de la manière suivante:

Une fois le port d'écoute démarré, ce dernier obtient deux unités d'exécution provenant du pool d'unités d'exécution correspondant au service d'écoute des messages.
Le port d'écoute crée un destinataire de message et une transaction sur chaque unité d'exécution. Les destinataires de message écoutent sur la destination sur laquelle le port d'écoute écoute également.
Les deux destinataires appellent la méthode receive() pour surveiller les messages sur la destination. Chaque destinataire tente d'obtenir les messages de la destination en premier.
Lorsqu'un destinataire extrait le message, il le traite en appelant la méthode onMessage() du bean MDB. L'autre destinataire continue d'appeler la méthode receive() pour écouter les messages sur la destination.

Comment éviter des délais d'expiration de transaction non souhaités

Si votre système de messagerie s'exécute en mode non ASF, pour éviter des délais d'expiration de transaction non souhaités, vous devez autoriser une durée de traitement suffisante avant d'atteindre le délai total du cycle de vie des transactions. Par conséquent, vous devez vous assurer que la valeur que vous spécifiez pour la propriété personnalisée du service d'écoute de messages NON.ASF.RECEIVE.TIMEOUT est inférieure à la valeur que vous spécifiez pour la propriété du service de transaction Total transaction lifetime timeout et que la différence entre les valeurs des deux propriétés est supérieure à la durée nécessaire à la méthode onMessage() du bean géré par message pour traiter le message.

Comme indiqué dans l'exemple suivant, si ces propriétés ne sont pas correctement configurées, les transactions peuvent arriver à expiration avant qu'elles ne se terminent. Cela est dû au fait que l'unité d'exécution commence à appeler la méthode receive() dès que la transaction est créée. Dans l'exemple suivant, NON.ASF.RECEIVE.TIMEOUT est défini sur 110000 millisecondes (110 secondes), Total transaction lifetime timeout est défini sur 120 secondes et la méthode onMessage () du bean géré par message prend 15 secondes pour traiter un message. L'exemple suppose qu'aucun message n'apparaît sur la destination tant que la méthode receive() n'est pas presque arrivée à expiration :

Le port d'écoute démarre. Il alloue une unité d'exécution provenant du pool d'unités d'exécution et crée une transaction et un destinataire de message sur l'unité d'exécution.
L'unité d'exécution appelle la méthode receive() afin de surveiller les messages.
Après 110 secondes, un message s'affiche sur la destination.
L'unité d'exécution supprime le message de la destination et appelle la méthode onMessage() du bean MDB pour commencer à traite le message.
Après 10 secondes, le délai d'expiration de la transaction est atteint. Le serveur d'applications marque la transaction pour annulation.
Après 5 secondes, la méthode onMessage() finit le traitement du message et tente de valider la transaction.
La durée totale écoulée depuis le démarrage de la transaction est de 125 secondes (110 secondes d'attente d'un message plus 15 secondes de traitement du message). Comme cette durée est supérieure au délai de transaction, le serveur d'applications empêche la validation de la transaction qui est alors annulée.

Pour plus d'informations sur la configuration des propriétés NON.ASF.RECEIVE.TIMEOUT et Total transaction lifetime timeout afin d'éviter les dépassements de délai de transaction indésirables, voir les tâches connexes.