WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

MQInput エラーの処理

MQInput ノードは、持続メッセージおよびトランザクション・メッセージのエラーを処理する際に特定のアクションを実行します。 トランザクション・メッセージが入力キューへロールバックされると、ノードは再試行処理を試みます。 非トランザクション・メッセージは、例外発生時に入力キューにロールバックされません。

非トランザクション・メッセージで検出されるエラーは、入力ノードにあるエラーの管理で説明されているとおりに処理されます。

このアクションについては、以下の表で要約されています。

エラー・イベント Failure ターミナルに接続している Failure ターミナルに接続していない Catch ターミナルに接続している Catch ターミナルに接続していない
ノードが内部エラーを検出 Failure ターミナルに接続されているフローがエラーを処理する メッセージは代替キューに書き込まれ、書き込みに失敗した場合はノードが再試行する 適用外 適用外
ノードがメッセージを out ターミナルに伝搬すると、out フローで例外が発生する 適用外 適用外 Catch ターミナルに接続されているフローがエラーを処理する ノードが再試行
ノードがメッセージを Catch ターミナルに伝搬すると、Catch ターミナルに接続されているフローで例外が発生する エラーがログに記録され、メッセージがロールバックされる エラーがログに記録され、メッセージがロールバックされる 適用外 適用外
ノードがメッセージを Failure ターミナルに伝搬すると、Failure ターミナルに接続されているフローで例外が発生する 適用外 適用外 ノードが再試行 ノードが再試行

再試行処理

メッセージが入力キューへロールバックされると、ノードは再試行処理を試みます。 ノードはメッセージが以前にバックアウトされているかどうかを調べ、バックアウトされている場合には、バックアウト・カウントがバックアウトしきい値に達しているか (等しいか) どうかを調べます。 各メッセージのバックアウト・カウントは、MQMD の WebSphere® MQ によって保守されます。

キューの作成時に、バックアウトしきい値属性 BOTHRESH を指定 (または、デフォルトでゼロ (0) になるように) します。 デフォルト値 0 を受け入れると、ノードはこの値を 1 に増やします。 ノードはまた、現行値を検出できなかった場合にもこの値を 1 に設定します。 バックアウトしきい値が 1 に設定されている場合、メッセージは 1 回処理されますが、MQInput ノードの Out ターミナル経由では再試行されません。 少なくとも 1 回メッセージを再試行する場合は、バックアウトしきい値を 2 に設定します。

  1. ノードがメッセージを Out ターミナルに伝搬した後に output フロー内で障害が発生するということが何度も繰り返され、再試行の回数がバックアウトしきい値の限度に達した場合、ノードは、Failure ターミナルに接続していれば、メッセージを Failure ターミナル経由で伝搬しようとします。 Failure ターミナルに接続していなかった場合、ノードは、別のキューにメッセージを書き込もうとします。 メッセージが Failure ターミナル経由で伝搬されると、例外リストには Out ターミナルまたは Catch ターミナルに接続されているフローで発生した例外は含まれません。例外リストには、そのメッセージが Failure ターミナルを通過した理由 (例えば、バックアウトしきい値が満たされたなど) をカバーする新規の例外が含まれます。

    Failure ターミナルの先で障害が発生した場合、MQMD のバックアウト・カウント・フィールドが入力キュー用に設定されたバックアウトしきい値の 2 倍に達するまで再試行が行われます。 この限度に達した場合、ノードは別のキューにメッセージを書き込もうとします。

  2. バックアウトしきい値に達していない場合、ノードはキューから再度メッセージを受け取ります。 失敗した場合は、内部エラーとして処理されます (前述のとおりです)。 正常に完了した場合、ノードはメッセージを out フローに伝搬します。
  3. バックアウトしきい値に達すると、次のようになります。
    • Failure ターミナルに接続した場合、ノードはメッセージをそのターミナルに伝搬します。 Failure ターミナルに接続されているフローでエラーを処理する必要があります。
    • Failure ターミナルに接続していなかった場合、ノードは、優先順位に従って使用可能キューにメッセージを書き込もうとします。
      1. 入力キューのバックアウト・リキュー名 (キュー属性 BOQNAME) が定義されていれば、メッセージはそのリキューに入れられます。
      2. バックアウト・キューが定義されていない場合、あるいはノードが識別できない場合、送達不能キュー (DLQ) が定義されていると、メッセージはそこに入れられます。 (ブローカーのキュー・マネージャーが mqsicreatebroker コマンドによって定義されている場合には、DLQ がデフォルト名 SYSTEM.DEAD.LETTER.QUEUE で定義されており、このキュー・マネージャーに使用可能です。)
      3. キューが存在しないなどの MQPUT エラーが発生しているため、またはキューがノードによって認識されないために、メッセージをこれらのキューのどちらにも書き込むことができない場合、メッセージを安全に処理することはできません (メッセージを失う危険があります)。

        メッセージは廃棄できないため、メッセージ・フローはメッセージのバックアウトを試行し続けます。 エラー状態は、ローカル・エラー・ログにエラーを書き込むことによって記録されます。 2 回目以降にこのエラーが示されるときには、入力キューのメッセージにある BackoutCount の値が継続的に増えていきます。

        キューが存在しないためにこの状態が発生している場合、上に挙げられているいずれかのバックアウト・キューを定義することによって解決できます。 何がメッセージの処理を妨げているのかがはっきりしている場合は、一時的に BOTHRESH 属性の値を増やすことができます。 このようにすることによって、メッセージには強制的に通常の処理が実行されます。

  4. バックアウトしきい値の 2 倍に達したり、2 倍を超えたりした場合、前のステップの説明のとおり、ノードは、優先順位に従って使用可能キューにメッセージを書き込もうとします。

トランザクション、イベント・モニター、およびバックアウトの処理

MQInput ノードは、再試行処理の実行時にメッセージをバックアウト・リキュー・キューまたは送達不能キューに入れることで、トランザクションをバックアウトできます。 入力キューからメッセージを受け取るときに、バックアウト・カウントが検査されます。バックアウトしきい値を超えている場合、メッセージは即時にバックアウトされ、そのメッセージに対するそれ以降の処理は実行されません。バックアウト操作は、以前の失敗処理とは別のトランザクションで発生し、バックアウト・トランザクションではメッセージの解析と検証は行われません。バックアウト・トランザクションでは固有のモニター・イベント・セットが生成されます。したがってメッセージ解析から得られる情報 (exceptionList など) が使用できないことがあります。

メッセージ・グループ・エラーの処理

WebSphere MQ はメッセージ・グループをサポートします。 メッセージを 1 つのグループに追加して、そのメッセージの処理を他のメッセージと連動させることを指定できます (つまり、すべてのメッセージをコミットするか、ロールバックするということです)。 グループとしてまとめたメッセージをブローカーに送信する場合、メッセージ・フローが正しく構成されていれば、この状態は維持され、グループ・メッセージの処理時にエラーは発生しません。

グループとしてまとめたメッセージを正しく処理するためにメッセージ・フローを構成するには、MQInput ノードで説明されている処置を実行してください。 ただし、メッセージのいずれかを処理中にエラーが発生した場合、メッセージ・グループの正しい処理は保証されません。

説明されているとおりに MQInput ノードを構成した場合、通常の環境下では、グループ内のすべてのメッセージが、グループ内の最後のメッセージが正常に処理された時点でコミットされる単一の作業単位で処理されます。 ただし、グループ内の最後のメッセージが処理される前にエラーが発生した場合には、エラーを生成したメッセージを含め、すべてのメッセージを組み込む作業単位が、ここで解説された規則によって定義されるエラー処理に従って処理されます。 その結果、その作業単位がバックアウトされることがあります。

ただし、グループ内に残っているメッセージはいずれも、メッセージ・フローによって正常に読み取られて処理され、新しい作業単位で処理されコミットされる可能性があります。 最後のメッセージが検出されて処理される時点で、コミットが発行されます。 したがって、グループ内でエラーが発生したが、それが最初または最後のメッセージではない場合には、グループの一部はバックアウトされ、他の部分はコミットされる可能性があります。

ユーザーのメッセージ処理要件では、この状態を特定の仕方で処理することが求められる場合は、メッセージ・グループ内のエラーを処理するための、追加のエラー処理を準備する必要があります。 例えば、データベース内のメッセージ・グループの障害を記録したり、 各メッセージの検索時にデータベース上にチェックを入れ、 現行グループにすでにエラーが検出されている場合にはロールバックを強制したりすることができます。 これにより、メッセージのグループ全体がバックアウトされ、すべてが正常に処理されるまでは処理されないことになります。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:19


タスク・トピックタスク・トピック | バージョン 8.0.0.5 | ac00414_