Example 4: Automatically stopping an MDB or SCA composite 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) or Service Component Architecture (SCA) composite 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), or a business-level application containing a Service Component Architecture (SCA) composite, that interacts with external system resources.

The destination to which the MDB or SCA composite 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, we need the following information:

• The enterprise application containing the MDB, or the business-level application containing the SCA composite.

• 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 or SCA composite is stopped. This property applies to sets of messages.

  If 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 or SCA composite. 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.

The JCA MBean emits JMX notifications to indicate that the MDB or SCA composite is paused, and that the MDB or SCA composite has resumed. Consider registering a message listener on the JCA MBean to receive the JMX notifications.

In this scenario, the enterprise application is a continuously running system that uses a deployed MDB or SCA composite 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 or SCA composite immediately, it is hidden for the Delay between failing message retries retry delay (five seconds in this scenario).

When the number of hidden messages reaches the Sequential failed message threshold, the MDB or SCA composite 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 or SCA composite stops automatically. A JMX notification is emitted by the JCA MBean and a log entry alerts the system administrator that the MDB has stopped.

1. Navigate to the deployed enterprise application containing the MDB or SCA composite.

2. From the MDB or SCA composite, navigate to its JMS activation specification. Click Resources -> JMS -> Activation specifications -> activation_specification_name.

3. Enter a value of 1 for the Sequential failed message threshold.

4. Enter a value of 5000 for the Delay between failing message retries.

5. Save the configuration.

6. Navigate to the destination to which the MDB or SCA composite 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

7. Under Exception destination, select None.

8. Enter a value of 5 in Maximum failed deliveries per message.

9. Save the changes to the master configuration.
   

10. When you receive a JMX notification and a log entry indicating that the MDB or SCA composite (or endpoint) has been paused, investigate the problem with the system resource that the MDB or SCA composite was using. While the MDB or SCA composite is paused, because no exception destination is configured, msg1 remains on the queue. No other messages are processed.

11. If we resume the MDB or SCA composite 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 (five 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.

12. Log on to the console again, navigate to the same enterprise application and click Resume on the administrative panel for the MDB or SCA composite. We can also resume the MDB or SCA composite by and the JCA MBean. The initial JMX notification and log entry indicate which MBean to use to resume the MDB or SCA composite. The MDB or SCA composite 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 or SCA composite is resumed, the JCA MBean emits a JMX notification to indicate that the MDB or SCA composite has resumed. Messages on the queue are consumed, messages that had failed are retried, and the transaction commits.