メッセージ処理の失敗と静止モード

Business Process Choreographer は、一時的なインフラストラクチャー障害を処理するための機能を提供します。

このセクションでは、失敗したメッセージをビジネス・プロセス・コンテナーによって処理する仕組みを説明します。この仕組みは、ヒューマン・タスクでの失敗したメッセージ処理で説明するヒューマン・タスク・コンテナーによって使用される簡略化された仕組みとは対照的です。

長期実行プロセスは、一連のトランザクションで構成されています。 トランザクションは、Java Message Service (JMS) メッセージによって分離されます。 サーバーは、メッセージ駆動型 Bean に送信します。 この Bean の処理は、着信メッセージをプロセス・サーバーに受け渡すことによって行います。 それぞれのトランザクションは、以下のアクションで構成されています。

サーバーは、以下の理由のいずれかで、メッセージ駆動型 Bean が受信したメッセージの処理に失敗することがあります。

これらの原因に対する対応は、以下のとおりです。

原因 応答
インフラストラクチャーが使用不可 メッセージ駆動型 Bean は、指定した期間、この状態からのリカバリーを試行します。 この Bean は、サーバーが再び作動可能になるまで、すべてのメッセージを使用可能な状態に保持するように試行します。 例えばこの問題は、データベース障害によって発生している場合があります。
メッセージの破損 指定した回数の試行後、メッセージは保留キューに書き込まれます。 この保留キューで、メッセージの操作および検討を行います。 保留キューから入力キューに戻して、トランザクションを再試行することもできます。

ビジネス・プロセス用のメッセージのインプリメンテーションは以下のとおりです。

メッセージ駆動型 Bean が静止モードで作動している場合、この Bean は、定期的にメッセージの処理を試行します。 処理に失敗したメッセージは、配信回数を増加させたり、保存キューの巡回数を増加させたりすることなく、保留キューに書き戻されます。メッセージの処理を正常に行うことが可能になったら、即時にメッセージ駆動型 Bean は標準処理モードにスイッチバックします。

この機能は、2 つの数値限度、2 つのキュー、静止モード、およびメッセージ再試行の動作から構成されています。

再試行限度

再試行限度は、 保留キューに書き込む前に保存キューでメッセージを転送できる最大回数を定義しています。

保存キューに書き込まれるには、メッセージの処理が 3 回失敗する必要があります。

例えば、再試行限度が 5 である場合は、メッセージが保存キューを 5 回通過してから (3 * 5 = 15 回失敗してから) 最後の再試行ループが開始されます。最後の再試行ループでさらに 2 回失敗すると、メッセージは保留キューに入れられます。 つまり、メッセージは、(3 * RetryLimit) + 2 回失敗してから保留キューに入れられます。

信頼できるインフラストラクチャーで実行中の、 パフォーマンスが重要なアプリケーションでは、 再試行限度を少なく、例えば 1 または 2 にしておく必要があります。

管理コンソールでこのパラメーターを見つけるには、「サーバー」 > 「アプリケーション・サーバー」 > server_name をクリックします。次に、「ビジネス・プロセス・コンテナー設定 (Business Process Container Settings)」見出しで、「ビジネス・プロセス・コンテナー」をクリックします。

保存キュー・メッセージ限度

保存キュー・メッセージ限度は、保存キューに入れることができるメッセージの最大数を定義します。保存キューがオーバーフローすると、システムは静止モードに入ります。 1 つのメッセージが失敗したら即時にシステムが静止モードに入るようにするには、 値をゼロに設定します。 ビジネス・プロセス・コンテナーのインフラストラクチャー障害に対する耐性を強化するには、値を増やします。

管理コンソールでこのパラメーターを見つけるには、「サーバー」 > 「アプリケーション・サーバー」 > server_name をクリックします。次に、「ビジネス・プロセス・コンテナー設定 (Business Process Container Settings)」見出しで、「ビジネス・プロセス・コンテナー」をクリックします。

保存キュー

保存キューは、障害を起こしたメッセージを保存します。 これらは、ビジネス・プロセス・コンテナーの内部作業キューへ戻すことによって再生されます。 メッセージは、3 回失敗したら保存キューに書き込まれます。 メッセージが (3 * RetryLimit) + 2 回失敗した場合は、保留キューに書き込まれます。 (再試行限度について詳しくは、再試行限度を参照してください。) 保存キューが保存キュー・メッセージ限度で定義された限度に達してから別のメッセージが失敗すると、キューはオーバーフローし、システムは静止モードに入ります。 管理者は、失敗したメッセージの照会と再生のタスクを実行して、 このキュー内のメッセージを内部キューに戻すことができます。

保留キュー

保留キューには、 (3 * RetryLimit) + 2 回失敗したメッセージが含まれます。 (再試行限度について詳しくは、再試行限度を参照してください。) 管理者は、失敗したメッセージの照会と再生のタスクを実行して、 このキュー内のメッセージを内部キューに戻すことができます。

メッセージの再生

管理者は、 保留キューまたは保存キューから内部キューへメッセージを戻すことができます。 この操作は、管理コンソールか管理コマンドを使用して実行できます。

静止モード

保存キューがオーバーフローすると、 静止モードに入ります。これが起こると、場合によっては一時的だが重大なインフラストラクチャー障害が発生したと想定されます。静止モードの目的は、システムが多数のリソースを使用しないようにすることですが、インフラストラクチャー障害は、ほとんどのメッセージがいずれにせよ失敗する可能性があることを意味します。静止モードでは、次のメッセージの処理を試行する前に 、2 秒間のシステム・スリープがあります。 メッセージが正常に処理されると即時に、システムは標準メッセージ処理を再開します。

ヒューマン・タスクでの失敗したメッセージ処理

ヒューマン・タスク・コンテナーには、保存キューや再試行限度がありません。保留キューがあるだけで、失敗したメッセージはこのキューに置かれ、このキューから再生することができます。


(c) Copyright IBM Corporation 2005, 2006. All rights reserved.
(c) Copyright IBM Japan 2006
このインフォメーション・センターでは、Eclipse テクノロジー (http://www.eclipse.org) が採用されています。