Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Administer Messaging resources > Manage messaging with the default messaging provider > Configure resources for the default messaging provider > Protect an MDB application from system resource problems
Example 4: Automatically stopping an MDB when no exception destination is specified
To prepare for a system resource becoming unavailable or a problem message, configure the system to stop the message-driven bean (MDB) automatically.
To maintain message ordering, do not use an exception destination. This task assumes that we have deployed an enterprise application containing a message-driven bean (MDB) that interacts with external system resources.
The destination to which the MDB listens must not use an exception destination, that is, the exception destination for the queue or topic space destination must be configured as none.
To complete this task, you need the following information:
- The enterprise application that contains the MDB.
- The dependent external system resources.
- A value of 1 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.
If this property is set to a value greater than 1, the system automatically resets it to 1 when an exception destination is configured as none.
- 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.
- An acceptable value for the Maximum failed deliveries per message, that is, the maximum number of failed attempts to process a message. This property applies to individual messages.
In this scenario, the enterprise application is a continuously running system that uses a deployed MDB to access an external system resource.
When a problem message (msg1 in this scenario) is encountered, it is put back on the queue.
Instead of msg1 being made available to the MDB immediately, it is hidden for the Delay between failing message retries retry delay (5 seconds in this scenario).
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 re-available. In this scenario, this threshold is reached as soon as msg1 is hidden.
When the Delay between failing message retries for msg1 expires, msg1 is unhidden and reprocessed.
This process is repeated until msg1 reaches its Maximum failed deliveries per message limit (five times in this scenario).
After msg1 is unhidden for the fourth time, rolled back and rehidden, the Sequential failed message threshold is reached 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.
Procedure
- Navigate to the deployed enterprise application that contains the MDB.
- From the MDB, navigate to its JMS activation specification. Click Resources -> JMS -> Activation specifications -> activation_specification_name .
- Enter a value of 1 for the Sequential failed message threshold.
- Enter a value of 5000 for the Delay between failing message retries.
- Save the configuration.
- Navigate to the destination to which the MDB is listening. Click one of the following paths, as appropriate:
- Service integration -> Buses -> bus_name -> [Destination resources] Destinations -> queue_name
- Service integration -> Buses -> bus_name -> [Destination resources] Destinations -> topic_space_name
- Under Exception destination, select None.
- Enter a value of 5 in Maximum failed deliveries per message.
- Save your changes to the master configuration.
- When you receive a JMX notification and a log entry indicating that the MDB (or endpoint) has been paused, investigate the problem with the system resource that the MDB was using. While the MDB is paused, because no exception destination is configured, msg1 remains on the queue. No other messages are processed.
- If you resume the MDB but the problem with the failing message continues, the maximum failed deliveries limit is reached on the first retry of the message, but because no exception destination is configured, the message is not moved to another queue. Instead, the whole queue point is blocked to all consumers for the Delay between failing message retries retry delay interval (5 seconds in this scenario). After this time, consumers begin again. If the failing message is still there, and fails again, the queue point is blocked for another 5 seconds. This process continues until you remove the failing message from the queue, either by deleting it manually or solving the problem with it, and in doing so allowing the consuming application to succeed in processing.
- Log on to the admin console again, navigate to the same enterprise application and click Resume on the administrative panel for the MDB. We can also resume the MDB by using scripting and the JCA MBean. The initial JMX notification and log entry indicate which MBean to use to resume the MDB. The MDB begins to be driven with the messages that are on the destination.
Results
You have configured the system to protect itself from external resource failures while maintaining message ordering.
What to do next
When the MDB is resumed, the JCA MBean emits a JMX notification to indicate that the MDB has resumed. Consider registering a message listener on the JCA MBean to receive the JMX notifications. Messages on the queue are consumed, messages that had failed are retried, and the transaction commits.