WAS v8.5 > Administer applications and their environment > Welcome to administering Messaging resources > Manage messaging with the default messaging provider > Configure resources for the default messaging provider > Protecting an MDB or SCA application from system resource problems

Example 2: Automatically stopping an MDB or SCA composite when a system resource becomes unavailable

To prepare for a system resource becoming unavailable, configure the system to stop the MDB or Service Component Architecture (SCA) composite automatically after a small number of message failures, and to alert you to the problem.

This task assumes that we have deployed an enterprise application containing a MDB, or a business-level application containing a SCA composite, that interacts with external system resources.

The destination to which the MDB or SCA composite listens must use an exception destination. This exception destination can be the system default, or one configured specifically for the destination.

To complete this task you need the following information:

In this scenario, the enterprise or business-level application is a continuously running system that uses a deployed MDB or SCA composite to access an external system resource.

If the external resource experiences a problem and becomes unavailable, the deployed MDB or SCA composite cannot access that resource, so the transaction associated with the MDB or SCA composite 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 or SCA composite.

Meanwhile, the MDB or SCA composite 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 or SCA composite 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 or SCA composite stops automatically. A JMX notification is emitted by the JCA MBean and a log entry alerts the system administrator the MDB has stopped.

In this scenario, the MDB or SCA composite is stopped automatically when the system resource has been unavailable for approximately 20 seconds. If the system resource is unavailable for a shorter time, and the sequential failure count does not reach the Sequential failed message threshold, messages are processed successfully on one of the retries. In effect, the system continues normally without manual intervention, and without sending any messages to the exception destination.

  1. cd deployed enterprise application containing the MDB, or the business-level application containing the 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 3 for the Sequential failed message threshold.

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

  5. Save the configuration.
  6. cd 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. Enter a value of 5 for the Maximum failed deliveries per message.

  8. Save your changes to the master configuration.

  9. When you receive a JMX notification and a log entry indicating the MDB or SCA composite (or endpoint) has been paused, investigate the problem with the system resource the MDB or SCA composite was using. While the MDB or SCA composite is paused, no messages are sent to the exception destination and no error messages appear in the console related to the stopped database.

  10. When the system resource that failed becomes available, restart it.
  11. Log on to the dmgr 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 using scripting 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.

When the MDB or SCA composite is resumed, the JCA MBean emits a JMX notification to indicate the MDB or SCA composite has resumed. Messages on the queue are consumed, messages that had failed are retried, and the transaction commits.


+

Search Tips   |   Advanced Search