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.
Before you begin
The destination to which the MDB listens must use an exception destination. This exception destination can be the system default, or one configured specifically for the destination.
- The enterprise application that contains the MDB.
- The dependent external system resource.
- A value of 3 for the Sequential failed message threshold. This is the maximum number of sequential failures of delivery of messages, after which the MDB is stopped. This property applies to sets of messages.
- A value of 5000 for the Delay between failing message retries, that is, the time in milliseconds before a failing message is available to be delivered to the MDB. Other messages might be delivered during this period, unless theSequential failed message threshold and the maximum concurrency is set to 1.
- A value of 5 for the Maximum failed deliveries per message, that is, the maximum number of failed attempts to process a message, after which the message is forwarded from its intended destination to the exception destination. This property applies to individual messages.
About this task
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 Delay between failing message retries, before it is made available to the MDB.
Meanwhile, the MDB processes the next message on the queue, msg2. The external resource is still unavailable, so the processing of this message also fails. The message transaction is rolled back and the message is hidden for five seconds. The next message on the queue, msg3, is processed, fails, and is also hidden.
When the number of hidden messages reaches the Sequential failed message threshold, the MDB will not process any further messages until one of the hidden messages becomes available again.
When the Delay between failing message retries for msg1 expires, msg1 is unhidden and reprocessed. Because the resource is still unavailable, the message is rehidden. The same thing happens to msg2 and msg3.
A message is considered a failed message when it is rolled back one less than the Maximum failed deliveries per message limit (five times in this scenario). So after msg1 is unhidden for the fourth time, rolled back and rehidden, the sequential failure count is incremented. At this point, msg2 becomes unhidden, rolled back and rehidden. Similarly, msg3 becomes unhidden, rolled back and rehidden. The sequential failure count reaches the Sequential failed message threshold and the MDB stops automatically. A JMX notification is emitted by the JCA MBean and a log entry alerts the system administrator that the MDB has stopped.