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
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.
- 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é.