Hitachi

OpenTP1 Version 7 OpenTP1 メッセージキューイング機能 TP1/Message Queue 使用の手引


2.3.7 チャネル確立再試行

チャネル確立再試行は,チャネルに通信障害が発生した時にチャネルを自動的に再確立する機能です。再試行には短期確立再試行と長期確立再試行があります。短期確立再試行および長期確立再試行の機能は,お互いに独立した機能です。それぞれを,単独で指定したり同時に指定したりできます。なお,同時に指定した場合は,短期確立再試行が終わってから長期確立再試行を実行します。

短期確立再試行の機能を使用する場合,TCP定義のmqtalccha定義コマンドの-bオプションに次に示す指定をしてください。

長期確立再試行の機能を使用する場合,TCP定義のmqtalccha定義コマンドの-bオプションに次に示す指定をしてください。

ただし,確立再試行回数×確立再試行間隔(秒)の時間は,実際に確立再試行を実行する時間と必ずしも一致しません。これは,実際に確立再試行を実行する時間にチャネルの確立処理時間を含むためです。特に,クラスタセンダチャネルでは,実際に確立再試行を実行する時間はさらに長くなります。チャネル確立再試行を実行する前に,メッセージ送信経路の再設定処理が完了するのをmqttcpcs定義コマンド-v stimオペランドに指定した間隔で確認するためです。また,確立再試行間隔はMQT共通定義のmqtttim定義コマンドの-t btimオペランドおよびbmtimオペランドで指定する基本タイマ値の影響を受けるため,動作間隔に誤差が発生することがあります。

チャネル確立の再試行が動作するのは,次に示す通信障害が発生した場合です。

〈この項の構成〉

(1) 確立再試行の詳細

通信障害が発生すると,KFCA16318-I(コネクション確立再試行開始)が出力されて確立再試行を実行します。

mqtalccha定義コマンドの-bオプションにbretrymcp=noを指定した場合,次に示す処理のどれかが発生した時点で確立再試行処理は完了します。

mqtalccha定義コマンドの-bオプションにbretrymcp=yesを指定した場合,次に示す処理のどれかが発生した時点で確立再試行処理は完了します。

チャネルを確立するまでに発生する通信障害,出力されるログメッセージ,および再試行処理内容を次の表に示します。

表2‒6 再試行処理(チャネル確立前)

通信障害の内容

出力するログメッセージ

mqtalccha定義コマンドの-bオプションまたは-vオプション

bretry=yes

または

bretrylg=yes

vretry=yes

bretrymcp=yes

bretry=yes

または

bretrylg=yes

vretry=no

bretrymcp=yes

bretry=yes

または

bretrylg=yes

vretry=yes

bretrymcp=no

bretry=yes

または

bretrylg=yes

vretry=no

bretrymcp=no

コネクション障害

(TCP/IPエラー)

KFCA16331-E

(TCP/IPインタフェースエラー)

時間監視障害

(開始応答受信監視タイムアウト)

KFCA16329-E

(受信監視タイムアウト)

監視対象=init

×

×

MCP障害

(チャネル属性不一致)

KFCA16341-E

(開始要求応答受け入れ不可)

理由コード=00,または理由コード15

×

×

MCP障害

(該当するチャネルがない)

KFCA16341-E

(開始要求応答受け入れ不可)

理由コード=01

×

×

MCP障害

(チャネルタイプの組み合わせが不正)

KFCA16341-E

(開始要求応答受け入れ不可)

理由コード=02

×

×

MCP障害

(相手キューマネジャが動作していない)

KFCA16341-E

(開始要求応答受け入れ不可)

理由コード=03

×

×

MCP障害

(相手キューマネジャが終了中)

KFCA16341-E

(開始要求応答受け入れ不可)

理由コード=05

×

×

MCP障害

(相手チャネルの状態が「チャネル停止」でない)

KFCA16341-E

(開始要求応答受け入れ不可)

理由コード=16

×

×

MCP障害

(上記以外のエラー応答受信)

KFCA16341-E

(開始要求応答受け入れ不可)

上記以外の理由コード

×

×

(凡例)

◎:チャネルが確立するまで再試行を実行します。

○:TCP/IPコネクション確立まで再試行を実行します。

×:再試行を実行しません。

チャネルの確立後に発生する通信障害と,出力されるログメッセージ,および再試行処理内容を次の表に示します。

表2‒7 再試行処理(チャネル確立後)

通信障害の内容

出力するログメッセージ

mqtalccha定義コマンドの-bオプションまたは-vオプション

bretry=yes

または

bretrylg=yes

vretry=yes

bretrymcp=yes

bretry=yes

または

bretrylg=yes

vretry=no

bretrymcp=yes

bretry=yes

または

bretrylg=yes

vretry=yes

bretrymcp=no

bretry=yes

または

bretrylg=yes

vretry=no

bretrymcp=no

コネクション障害

(TCP/IPエラー)

KFCA16331-E

(TCP/IPインタフェースエラー)

時間監視障害

(確認メッセージ受信監視タイムアウト)

KFCA16329-E

(受信監視タイムアウト)

監視対象=resp

×

×

時間監視障害

(接続セグメント受信監視タイムアウトまたは継続メッセージ受信監視タイムアウト)

KFCA16329-E

(受信監視タイムアウト)

監視対象=next

×

×

時間監視障害

(ハートビート間隔監視タイムアウト)

KFCA16329-E

(受信監視タイムアウト)

監視対象=htbt

×

×

MCP障害

(受信メッセージをあて先キューまたはデッドレターキューに登録失敗)

KFCA16345-E

(エラーデータ受信)

理由コード=06

×

×

MCP障害

(メッセージシーケンス番号不一致)

KFCA16343-E

(メッセージシーケンス番号不一致)

×

×

MCP障害

(キューファイル障害)

KFCA16333-E

(キューファイル障害)

または

KFCA16315-E

(キューが他サーバで使用中)

×

×

MCP障害

(上記以外のMCP障害)

KFCA16345-E

(エラーデータ受信)

×

×

(凡例)

◎:チャネルが確立するまで再試行を実行します。

○:TCP/IPコネクション確立まで再試行を実行します。

×:再試行を実行しません。

チャネルの確立後に発生した通信障害によって確立再試行を実行する場合,再試行回数の残数は元に戻ります。このため,通信障害が解決されない場合,次に示す順番で処理が繰り返し実行されます。

  1. チャネル(TCP/IP)確立(確立再試行回数の残数=チャネル定義の値)

  2. 通信障害発生

  3. チャネル解放

  4. 確立再試行処理(確立再試行回数の残数=現在の残数−1)

  5. チャネル(TCP/IP)確立(確立再試行回数の残数=チャネル定義の値)

  6. 通信障害発生

確立再試行回数の残数は0にならないため,無限回の確立再試行を実行することがありますので,注意してください。

確立再試行処理の全体の流れを以降の図に示します。

図2‒22 短期および長期確立再試行処理の概要(TCP/IPコネクション確立までの再試行)

[図データ]

図中の1〜10について説明します。

  1. コネクション障害または時間監視障害が発生

  2. 障害ログメッセージの出力(表2-6および表2-7を参照)

  3. 短期確立再試行を実行する場合(mqtalccha定義コマンドの-bオプションにbretry=yesを指定),または長期確立再試行を実行する場合(mqtalccha定義コマンドの-bオプションにbretrylg=yesを指定)は,再試行開始ログメッセージ(KFCA16318-I種別=shortまたはKFCA16318-I種別=long)の出力

  4. 再試行間隔(短期確立再試行または長期確立再試行)のタイマの設定

  5. 指定した再試行間隔(短期確立再試行または長期確立再試行)の経過を待つ

  6. コネクション障害の発生の確認

    • コネクション障害が発生した場合,再試行回数の残数を更新して次の確立再試行を実行します。

    • コネクション障害が発生していない場合,確立再試行は完了します(再試行回数の残数はチャネル定義の値に戻ります)。

  7. 確立再試行回数の残数が0になっていないかの確認

  8. 短期再試行中の場合,回数オーバーログメッセージ(KFCA16340-I種別=short)の出力。長期再試行中の場合,回数オーバーログメッセージ(KFCA16340-I種別=long)の出力。

  9. 長期確立再試行を実行する場合,確立再試行回数の残数を設定して長期再試行処理開始ログメッセージ(KFCA16318-I種別=long)の出力

  10. 前回の障害と同じ障害かどうか確認し,同じ障害でなければ該当障害のログメッセージの出力(表2-6および表2-7を参照)

    図2‒23 短期および長期確立再試行処理の概要(チャネル確立までの再試行)

    [図データ]

図中の1〜11について説明します。

  1. MCP障害が発生

  2. 障害ログメッセージの出力(表2-6および表2-7を参照)

  3. 短期確立再試行を実行する場合(mqtalccha定義コマンドの-bオプションにbretry=yesを指定),または長期確立再試行を実行する場合(mqtalccha定義コマンドの-bオプションにbretrylg=yesを指定),再試行開始ログメッセージ(KFCA16318-I種別=shortまたはKFCA16318-I種別=long)の出力

    ただし,MCP障害の確立再試行が設定されている(mqtalccha定義コマンドの-bオプションにbretrymcp=yesを指定)場合に限ります。

  4. 再試行間隔(短期確立再試行または長期確立再試行)のタイマの設定

  5. 指定した再試行間隔(短期確立再試行または長期確立再試行)の経過を待つ

  6. コネクション障害の発生の確認

    • コネクション障害が発生した場合,確立再試行回数の残数を更新して次の確立再試行を実行します。

    • コネクション障害が発生していない場合,チャネル開始要求を送信します。

  7. コネクション障害,時間監視障害,またはMCP障害のうちどれかについて発生の確認

    • コネクション障害,時間監視障害,またはMCP障害のどれかが発生した場合,確立再試行回数の残数を更新して確立再試行を実行します。

    • コネクション障害,時間監視障害,またはMCP障害のどれにも発生していない場合,確立再試行は完了します(再試行回数の残数は,チャネル定義の値に戻ります)。

  8. 確立再試行回数の残数(0になっていないか)の確認

  9. 短期再試行中の場合,回数オーバーログメッセージ(KFCA16340-I種別=short)の出力。また,長期再試行中の場合,回数オーバーログメッセージ(KFCA16340-I種別=long)の出力

  10. 長期確立再試行を実行する場合,確立再試行回数の残数を設定して長期再試行処理開始ログメッセージ(KFCA16318-I種別=long)の出力

  11. 前回の障害と同じ障害かどうか確認し,同じ障害でなければ該当障害のログメッセージの出力(表2-6および表2-7を参照)

(2) MCP障害による再試行(bretrymcp=yes)の効果

TCP定義のmqtalccha定義コマンドの-bオプションにbretrymcp=yesを指定している場合,mcp障害時に確立再試行が実行されます。bretrymcp=noを指定している場合,mcp障害時にチャネルは終了します。チャネル確立前,およびチャネル確立後の通信障害の種類とTCP定義のmqtalccha定義コマンドの-b bretrymcpオペランドの指定値(yesまたはno)との関係については表2-6および表2-7を参照してください。

チャネル確立再試行は,従来のTCP/IPレベルの再試行だけでなく,MQプロトコルレベルでの再試行が実行できるため,特に次に示す場合に効果があります。

KFCA16341-E(開始要求の応答受け入れ不可)出力時の再試行

チャネル確立時に,次に示す状況でKFCA16341-E(開始要求の応答受け入れ不可)が出力され,MCAが確立処理を中断することがあります。このような場合,コーラチャネルに対して再度チャネル開始コマンドを入力して,チャネルを開始する必要がありました。

チャネル確立再試行を使用すると,これらのエラーに対して自動的にチャネル確立再試行を実行し,相手システムの回復を待って,再確立を実行できます。

KFCA16341-E出力時の状況
回線障害によるチャネル状態の不一致

チャネルが使用しているTCP/IPプロトコルでは,回線に障害が発生しても一定時間障害を検出できないことがあります。このため,コーラチャネルが先に障害を検出してレスポンダチャネルの障害検出が遅れた場合に,コーラチャネルからのチャネル確立処理によってチャネル状態不一致が発生したとき,レスポンダにはKFCA16317-E(状態不一致)が出力され,コーラにはKFCA16341-E(開始要求の応答受け入れ不可。理由コード=16)が出力されます。なお,理由コード=16は,チャネルは使用できない状態であることを意味します。

IBM MQでのリスナとキューマネジャの開始状態の不一致

IBM MQでは,リスナとキューマネジャの開始状態が一致しない場合があります。このため,IBM MQのキューマネジャの終了中に,TP1/Message Queueのコーラチャネルが確立要求するとKFCA16341-E(開始要求の応答受け入れ不可。理由コード=03または05)が出力されます。理由コード=03は,IBM MQのキューマネジャが動作していないことを表します。なお,理由コード=05は,IBM MQのキューマネジャが終了処理中であることを表します。

チャネル状態の不一致(相手チャネルの状態が「チャネル停止」でない)

チャネルの終了直後に,MCAを再起動しようとすると,相手システムのMCAが終了中で,チャネルが確立できないため,KFCA16341-E(開始要求の応答受け入れ不可。理由コード=16)が出力され,チャネルが確立できないことがあります。bretrymcp=yesを指定していない場合は,相手システムの状態を確認したあと,もう一度mqtstachaコマンドでチャネルを開始してください。ただし,トリガ機能を使用している場合は,自動的にトリガメッセージが再作成され再度MCAが起動されます。