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 循序失敗訊息臨界值. 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 失敗訊息重試的延遲間隔, 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 the循序失敗訊息臨界值 and the maximum concurrency is set to 1.
- A value of 5 for the 每個訊息的失敗遞送次數上限, 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 失敗訊息重試的延遲間隔, 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 循序失敗訊息臨界值, the MDB will not process any further messages until one of the hidden messages becomes available again.
When the 失敗訊息重試的延遲間隔 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 每個訊息的失敗遞送次數上限 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 循序失敗訊息臨界值 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.