Example 2: Automatically stopping an MDB when a system resource becomes unavailable

To prepare for a system resource becoming unavailable, configure the system to stop the message-driven bean (MDB) automatically after a small number of message failures, and to alert you to the problem.

Avant de commencer

Cette tâche suppose que vous avez déployé une application d'entreprise contenant un bean géré par message qui interagit avec des ressources système externes.

La destination sur laquelle le bean géré par message est en mode écoute doit utiliser une destination d'exception. Cette destination d'exception peut être la valeur par défaut du système ou une valeur configurée spécifiquement pour la destination.

Pour exécuter cette tâche, vous avez besoin des informations suivantes :
  • L'application d'entreprise qui contient le bean géré par message.
  • Ressource système externe dépendante.
  • Une valeur 3 pour l'option Seuil d'échecs de messages séquentiels. Il s'agit du nombre maximal d'incidents de distribution de message séquentiels, au delà duquel le bean géré par message est arrêté. Cette propriété s'applique à des ensembles de messages.
  • A value of 5000 for the Fréquence entre deux échecs de message, that is, the time in milliseconds before a failing message is available to be delivered to the MDB. D'autres messages peuvent être distribués au cours de cette période, sauf si l'optionSeuil d'échecs de messages séquentiels et le nombre maximal d'accès concurrents ont la valeur 1.
  • Une valeur 5 pour l'option Nombre maximal de remises par message, à savoir, le nombre maximal de tentatives de traitement d'un message défectueuses, après quoi le message est transmis de sa destination prévue à la destination d'exception. Cette propriété s'applique à des messages spécifiques.

Pourquoi et quand exécuter cette tâche

In this scenario, the enterprise or business-level application is a continuously running system that uses a deployed MDB to access an external system resource.

If the external resource experiences a problem and becomes unavailable, the deployed MDB cannot access that resource, so the transaction that is associated with the MDB is rolled back and the message, msg1, is put back on the queue.

The message msg1 is hidden for a retry delay of five seconds, set in Fréquence entre deux échecs de message, before it is made available to the MDB.

Meanwhile, the MDB processes the next message on the queue, msg2. La ressource externe n'étant toujours pas disponible, le traitement de ce message échoue également. La transaction du message est annulée et le message est masqué pour cinq secondes. Le message suivant dans la file d'attente, msg3, est traité, échoue et est également masqué.

When the number of hidden messages reaches the Seuil d'échecs de messages séquentiels, the MDB will not process any further messages until one of the hidden messages becomes available again.

Lorsque le Fréquence entre deux échecs de message de msg1 arrive à expiration, msg1 n'est plus masqué et il est à nouveau traité. La ressource n'étant pas disponible, le message est à nouveau masqué. Il en est de même pour les messages msg2 et msg3.

Un message est considéré comme ayant échoué s'il est annulé une fois de moins que la limite Nombre maximal de remises par message (cinq fois dans ce scénario). Par conséquent, une fois que msg1 est affiché pour la quatrième fois, annulé, puis masqué de nouveau msg1, le nombre séquentiel d'incidents est incrémenté. A ce stade, msg2 est affiché, annulé, puis masqué de nouveau. De même, msg3 est affiché, annulé, puis masqué de nouveau. Le nombre séquentiel d'incidents atteint la limite Seuil d'échecs de messages séquentiels et le bean géré par message s'arrête automatiquement. Une notification JMX est émise par le bean géré par message JCA et une entrée de journal prévient l'administrateur système que le bean géré par message s'est arrêté.

Remarque : In this scenario, the MDB is stopped automatically when the system resource has been unavailable for approximately 20 seconds. Si la ressource système n'est pas disponible pour un court moment, et que le nombre séquentiel d'incidents n'atteint pas Seuil d'échecs de messages séquentiels, des messages sont traités avec succès sur l'une des relances. En effet, le système poursuit normalement sans intervention manuelle, et sans envoyer de messages à la destination d'exception.

Procédure

  1. Accédez à l'application d'entreprise déployée qui contient le bean géré par message.
  2. A partir du bean géré par message, accédez à sa spécification d'activation JMS. Cliquez sur Ressources -> JMS->Spécifications d'activation -> nom_spécification_activation.
  3. Entrez la valeur 3 pour l'option Seuil d'échecs de messages séquentiels.
  4. Entrez une valeur de 5000 pour Fréquence entre deux échecs de message.
  5. Enregistrez la configuration.
  6. Accédez à la destination sur laquelle le bean géré par message est en mode écoute. Cliquez sur l'un des chemins suivants, comme approprié :
    • Intégration des services -> Bus -> nom_bus -> [Ressources de la destination] Destinations -> nom_file_attente
    • Intégration des services -> Bus -> nom_bus -> [Ressources de la destination] Destinations -> nom_espace_sujet
  7. Entrez la valeur 5 pour l'option Nombre maximal de remises par message.
  8. Sauvegardez les modifications de la configuration principale.
  9. Si vous recevez une notification JMX et une entrée de journal indiquant que le bean géré par message (ou le noeud final) a été interrompu, identifiez l'incident relatif à la ressource système que le bean géré par message utilisait. Pendant que le bean géré par message est interrompu, aucun message n'est envoyé à la destination d'exception et aucun message d'erreur relatif à la base de données arrêtée n'apparaît dans la console.
  10. Lorsque la ressource système qui a échoué devient disponible, redémarrez-la.
  11. Log on to the administrative console again, navigate to the same enterprise application and click Resume on the administrative panel for the MDB. You can also resume the MDB by using scripting and the JCA MBean. La notification JMX initiale et l'entrée de journal indiquent le bean géré par message à utiliser pour reprendre le bean géré par message. Le bean géré par message commence à être piloté avec les messages qui se trouvent sur la destination.

Résultats

Vous avez configuré le système pour qu'il se protège des incidents de ressource externe.

Que faire ensuite

Lorsque le bean géré par message est repris, le MBean JCA émet une notification JMX pour indiquer que le bean géré par message fonctionne de nouveau. Les messages de la file d'attente sont utilisés, les messages ayant échoué font l'objet d'une nouvelle tentative et la transaction est validée.

Icône indiquant le type de rubrique Rubrique de tâche



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=tjn_mdb_0001_Ex2
Nom du fichier : tjn_mdb_0001_Ex2.html