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

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

集約のタイムアウト値の設定

集約ノードの 2 つのプロパティーを使用して、集約されるメッセージを処理するためのタイムアウト値を設定することができます。

始める前に:
このタスクを完了するには、以下のタスクを完了している必要があります。
次の 2 つの状況でタイムアウトの使用が必要になることがあります。
  • 集約された応答メッセージを指定の時間内に受け取る必要があるとき。 この状況では、AggregateControl ノードの「タイムアウト」プロパティーを設定します。
  • 認識されないメッセージを Unknown ターミナルに伝搬させる前に待機する必要があるとき。 この状況では、AggregateReply ノードの「不明なメッセージ・タイムアウト」プロパティーを設定します。
以下のセクションでは、それぞれの状況についてさらに詳しく説明します。

集約された応答メッセージを指定の時間内に受け取る

集約された応答メッセージを指定の時間内に受け取ることが必要な状況があるかもしれません。 戻りが遅い応答メッセージや、まったく戻ってこない応答メッセージがあるかもしれません。 このような状況では、 以下のいずれかの手順を使用して、ファンアウト・メッセージ・フローを開いてタイムアウト間隔を設定します。
AggregateControl ノードに対して直接行う場合
AggregateControl ノードの「タイムアウト」プロパティーを設定して、ブローカーが応答を待機する必要のある秒数を指定します。 デフォルトでは、このプロパティーは 0 (ゼロ) に設定されています。 これは、タイムアウトなしで、ブローカーが無期限で待機することを意味します。詳しくは、AggregateControl ノードを参照してください。
Aggregation 構成可能サービスを使用する場合
Aggregation 構成可能サービスを使用して、タイムアウトの間隔を指定することもできます。 AggregateControl ノード上の「集約名」プロパティーと同じ名前で Aggregation 構成可能サービスを作成し、構成可能サービスの timeoutSeconds プロパティーにタイムアウト値を指定することができます。 あるいは、実行グループと同じ名前で Aggregation 構成可能サービスを作成することもできます。 Aggregation 構成可能サービスからの値は、次のような順序で取られます。
  1. 「集約名」プロパティーで定義される集約と同じ名前の Aggregation 構成可能サービスが存在する場合は、その構成可能サービスが使用されます。
  2. 集約と同じ名前の構成可能サービスが存在しないものの、実行グループと同じ名前の構成可能サービスが存在する場合は、その構成可能サービスが使用されます。

実行グループと同じ名前の Aggregation 構成可能サービスが存在する場合、それは実行グループの中のすべての集約に使用できます。 ただし、実行グループの中の集約と同じ名前の構成可能サービスが存在する場合には、その特定の集約に使用されます。 それぞれのケースにおいて、構成可能サービスの timeoutSeconds プロパティーの値が、AggregateControl ノードの 「タイムアウト」プロパティーをオーバーライドします。

Aggregation 構成可能サービスについての詳細は、構成可能サービスのプロパティーを参照してください。

着信メッセージから動的に行う場合

AggregateControl ノードの「タイムアウトの場所」プロパティーを使用して、 着信メッセージ内のタイムアウト値の場所を指定できます。 この方法で指定したタイムアウト値は、AggregateControl ノードと集約構成可能サービスで指定された値を指定変更します。

詳しくは、AggregateControl ノードを参照してください。

タイムアウトの優先順位は、 次のような順序で、メッセージで設定されている値、構成可能サービスの値、またはノードの値によって決まります。
  1. タイムアウト値が着信メッセージの中で指定されている (AggregateControl ノードの「タイムアウト場所」プロパティーで指定された場所にある) 場合は、この値が使用されます。
  2. 「タイムアウト場所」プロパティーに場所が指定されていないか、メッセージ内のその場所が空であるか存在しない場合には、Aggregation 構成可能サービスの timeoutSeconds プロパティーで指定される値 (存在する場合) が使用されます。
  3. Aggregation 構成可能サービスが定義されていないか、または構成可能サービスの timeoutSeconds プロパティーが設定されていない場合には、AggregateControl ノードの Timeout プロパティーに設定された値が使用されます。

デフォルトでは、タイムアウト・ポーリングが 5 秒ごとに発生します。 そのため、「タイムアウト」プロパティーに 5 の倍数でない値を設定すると、余分な遅延が発生します。 例えば、「タイムアウト」プロパティーを 7 秒に設定すると、次回のタイムアウト・ポーリングまで 3 秒の遅延が発生します。 デフォルトのタイムアウト・ポーリング間隔を変更するには、環境変数 MQSI_AGGR_WAIT_TIMEOUT を使用します。 有効な値は 1000 ミリ秒から 5000 ミリ秒までです。 デフォルトのポーリング間隔を変更するときには、ブローカーを停止してから、MQSI_AGGR_WAIT_TIMEOUT 環境変数を設定した環境でブローカーを再始動します。

タイムアウトのインターバルが経過したのにすべての応答が到着していない場合は、到着した応答が、対応する AggregateReply ノードによって、集約された応答メッセージにされ、そのノードの Timeout ターミナルに伝搬されます。 この部分的な応答メッセージは、集約された完全な応答メッセージと同様に処理できます。 必要であれば、未完了の集約された応答の特殊処理を提供することができます。

認識されないメッセージを Unknown ターミナルに伝搬させる前に待機する

メッセージが AggregateReply ノードの In ターミナルに到着すると、それが予期された応答メッセージかどうかが検査されます。 認識されない場合、そのメッセージは Unknown ターミナルに伝搬されます。 以下の理由で、 メッセージを伝搬する前にブローカーを指定の期間待機させる場合があります。
  • 応答メッセージの到着が、AggregateRequest ノードによって実行された作業がトランザクションとしてコミットされる前だった場合。 この状況は、集約ファンアウト・フローの作成で説明されているとおりに、入力ノードの「トランザクション・モード」プロパティーを構成することで回避できます。
  • 応答メッセージの到着が、制御メッセージの到着する前だった場合。 この状況は、AggregateControl ノードの制御ターミナルを未接続のままにしておくことで回避できます。 Control ターミナルの接続の影響について詳しくは、集約フローでの制御メッセージの使用を参照してください。
これらの状況が最も生じやすいのは要求メッセージを同期点以外から送信した場合です。 結果として、有効な応答が Unknown ターミナルに送信されることがあります。 この事態が発生する可能性を低くするには、次の手順を実行します。
  1. ファンイン・メッセージ・フローを開きます。
  2. AggregateReply ノードの「不明なメッセージ・タイムアウト」プロパティーを設定します。

    このプロパティーを設定すると、有効な応答として即時に認識されなかったメッセージが、指定の秒数に渡ってブローカーの内部に保留されます。

不明タイムアウトのインターバルが満了してもメッセージが認識されている場合、メッセージは処理されます。 ノードは、以前は不明だったメッセージが有効なメッセージが集約の完成に必要な最後の応答であるかどうかを調べるために検査を行います。 もしそうであれば、集約応答メッセージが構成されて、伝搬されます。

不明タイムアウトのインターバルが満了してもメッセージが依然として認識されていない場合、メッセージは以前と同様 Unknown ターミナルに伝搬されます。

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

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

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


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