例 4: 例外宛先が指定されていない場合は MDB を自動的に停止する

システム・リソースが使用不可になった場合または問題メッセージに対して備えるため、メッセージ駆動型 Bean (MDB) を自動的に停止するようシステムを構成します。 メッセージ順序を維持するため、例外宛先は使用しません。

始める前に

このタスクは、外部システム・リソースと対話するメッセージ駆動型 Bean (MDB) を含んでいるエンタープライズ・アプリケーションがデプロイ済みであることを前提としています。

MDB が listen している宛先で、例外宛先を使用してはなりません。 つまり、キューまたはトピック・スペース宛先の例外宛先は、なしで構成する必要があります。

このタスクを実行するには、以下の情報が必要です。
  • MDB を含んでいるエンタープライズ・アプリケーション。
  • 従属外部システム・リソース。
  • 連続障害メッセージのしきい値」に値 1。 これはメッセージ配信の連続障害の最大数で、その数を超えると MDB が停止します。 このプロパティーは、メッセージの集合に 適用されます。
    注: このプロパティーが 1 より大きい値に設定されている場合、例外宛先がなしに構成されていると、システムは自動的に 1 にリセットします。
  • 障害のあるメッセージの再試行間の遅延」に値 5000。 これは、障害のあるメッセージが MDB に送達可能になるまでの時間 (ミリ秒) です。 連続障害メッセージのしきい値および最大並行性が 1 に設定されている場合を除き、他のメッセージはこの期間内に送達される可能性があります。
  • 1 メッセージ当たりの最大デリバリー失敗数」に対する許容値。つまり、メッセージ処理試行の失敗の最大数。このプロパティーは、個々のメッセージに 適用されます。

JCA MBean は JMX 通知を発行して、MDB が停止したこと、および MDB が再開したことを示します。 JCA MBean にメッセージ・リスナーを登録して、JMX 通知を受け取ることを検討してください。

このタスクについて

このシナリオでは、エンタープライズ・アプリケーションは、連続的に実行しているシステムであり、外部システム・リソースにアクセスするために、デプロイされた MDB を使用しています。

問題 メッセージ (このシナリオでは msg1) があると、それはキューに 戻されます。

msg1 は MDB ですぐに使用できるようになるのではなく、障害のあるメッセージの再試行間の遅延に設定された再試行遅延の間 (このシナリオでは 5 秒) は隠蔽されます。

隠蔽されたメッセージの数が連続障害メッセージのしきい値に達すると、隠蔽されたメッセージの 1 つが再度使用可能になるまで、MDB はそれ以上のメッセージを処理しなくなります。 このシナリオでは、msg1 が 隠蔽されるとすぐに、このしきい値に達します。

msg1 の障害のあるメッセージの再試行間の遅延が満了になると、msg1 は隠蔽が解除され、再処理されます。

このプロセスは、msg1 がその1 メッセージ当たりの最大デリバリー失敗数限度 (このシナリオでは 5 回) に達するまで繰り返されます。

msg1 が 4 回目に隠蔽解除され、ロールバックされ、再び隠蔽されると、「連続障害メッセージのしきい値」に達し、MDB は自動的に停止します。 JCA MBean によって JMX 通知が発行され、 ログ・エントリーがシステム管理者に MDB が停止したことを警告 します。

手順

  1. MDB が含まれているデプロイ済みエンタープライズ・アプリケーションまでナビゲートします。
  2. MDB からその JMS アクティベーション・スペックまでナビゲートします。 リソース (Resources) ->「JMS」 ->「アクティベーション・スペック」 ->「activation_specification_nameをクリックします。
  3. 連続障害メッセージのしきい値」に値 1 を入力します。
  4. 障害のあるメッセージの再試行間の遅延」に値 5000 を入力します。
  5. 構成を保存します。
  6. MDB が listen している宛先までナビゲートします。 以下のいずれかのパスを適宜クリックします。
    • サービス統合 ->「バス」 -> 「bus_name -> [宛先リソース (Destination resources)]「宛先 (Destinations)」 -> 「queue_name
    • サービス統合 ->「バス」 -> 「bus_name -> [宛先リソース (Destination resources)]「宛先 (Destinations)」 ->「topic_space_name
  7. 例外宛先」で、「なし」を選択します。
  8. 1 メッセージ当たりの最大デリバリー失敗数」に値 5 を入力します。
  9. 変更をマスター構成に保存します。
  10. MDB (またはエンドポイント) が休止したことを示す JMX 通知とログ・エントリーを受け取ったら、MDB が使用していたシステム・リソースの問題を調査します。 MDB が休止している間は、例外宛先が構成されていないため、msg1 はキューにとどまります。 他のメッセージは処理されません。
  11. MDB を再開しても障害のあるメッセージの問題が続く場合、メッセージを最初に再試行した時点で、最大デリバリー障害数制限に達しますが、例外宛先が構成されていないため、メッセージは別のキューには移動されません。 その代わりに、障害のあるメッセージの再試行間の遅延再試行遅延間隔 (このシナリオでは 5 秒) の間、キュー・ポイント全体がすべてのコンシューマーに対してブロックされます。 この時間 が過ぎると、コンシューマーは再び開始します。障害のあるメッセージがまだあり、再び障害が起こると、キュー・ポイントはまた 5 秒間ブロックされます。 この処理は、障害のあるメッセージをキューから取り除くまで続きます。メッセージの除去は、手動で削除するか、または、そのメッセージの問題を解決することで行い、そうすることで、 コンシュームするアプリケーションの処理が正常に実行されるようになります。
  12. もう一度管理コンソールにログオンし、同じエンタープライズ・アプリケーションまでナビゲートし、MDB の管理パネルで「再開」をクリックします。 スクリプトおよび JCA MBean を使用して MDB を再開することもできます。 最初の JMX 通知とログ・エントリーに、どの MBean を使用して MDB を再開するのかが示されます。 宛先にあるメッセージで MDB の駆動が開始します。

タスクの結果

システムは、メッセージ順序を維持したまま外部リソース 障害から保護されるように構成されます。

次のタスク

MDB が再開されると、JCA MBean は、MDB が再開したことを示す JMX 通知を発行します。 キューにあるメッセージがコンシュームされ、 障害のあったメッセージは再試行され、トランザクションはコミットします。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjn_mdb_0001_Ex4
ファイル名:tjn_mdb_0001_Ex4.html