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

This task assumes that you 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 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:
  • 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.

Note: In this scenario, the MDB 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 循序失敗訊息臨界值, 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.

Procedure

  1. Navigate to the deployed enterprise application that contains the MDB.
  2. From the MDB, navigate to its JMS activation specification. Click 資源 -> JMS -> 啟動規格 -> activation_specification_name.
  3. Enter a value of 3 for the 循序失敗訊息臨界值.
  4. Enter a value of 5000 for the 失敗訊息重試的延遲間隔.
  5. Save the configuration.
  6. Navigate to the destination to which the MDB is listening. Click one of the following paths, as appropriate:
    • 服務整合 -> 匯流排 -> bus_name -> [目的地資源] 目的地 -> queue_name
    • 服務整合 -> 匯流排 -> bus_name -> [目的地資源] 目的地 -> topic_space_name
  7. Enter a value of 5 for the 每個訊息的失敗遞送次數上限.
  8. 儲存對主要配置所做的變更。
  9. 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, 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 administrative console again, navigate to the same enterprise application and click Resume on the administrative panel for the MDB. You 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.

What to do next

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

指出主題類型的圖示 作業主題



時間戳記圖示 前次更新: July 9, 2016 11:15
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjn_mdb_0001_Ex2
檔名:tjn_mdb_0001_Ex2.html