| オペレーション呼び出しでの障害 |
クライアントアプリケーションからサーバアプリケーションに対するオペレーション呼び出しに失敗した場合の調査方法を説明します。
調査のためには、何の呼び出しが何のエラーになったのかを確認する必要があります。
何のエラーかだけで調査が可能な場合もありますが、通信障害や遅延/無応答などの障害ではエラー
情報で相手が特定できません。何の呼び出しがエラーになったのかを確認することで対象を絞り込むこ
とができます。
あらゆるCORBA システム例外で、minor 番号が3840〜4095 の範囲にある場合は、WebOTX のサーバ実
行環境からエラーを受けています。WebOTX のサーバ実行環境上で何らかの問題が起きています。
以下に、主な障害について説明します。
・NO_RESPONSE(3927) → 実行時間超過への対応
・UNKNOWN(3923) → ネイティブ例外への対応
・UNKNOWN(3926) → APアボートへの対応
・UNKNOWN(3934) → プロセスの突然終了への対応
・NO_RESOURCES(3840) → キュー滞留超過への対応
・NO_RESOURCES(3844) → リクエストの多重度超過への対応
・INV_OBJREF(3960) → アプリケーショングループ未起動への対応
・INV_OBJREF(3880) → プロセスグループ未起動への対応
実行環境が返す例外一覧はメッセージ編で説明しているのでそちらも参照してください。
通信障害の発生を意味します。オペレーション呼び出し時のCOM_FAILUREなら実行基盤との間で問題があり、 リファレンス取得でのCOM_FAILUREなら名前サーバとの間で問題がおきています。
・COM_FAILURE(RESET) → サーバからの切断への対応
・COM_FAILURE(REFUSE) → サーバポート未開設への対応
名前サーバから取得しようとしたリファレンスが存在しない場合に本エラーになります。
リファレンスの登録をAP起動と同期して行っている場合(一時的な登録の場合)、APが起動していない可能性があります。
→ プロセスグループ未起動への対応
リファレンスの登録時にラウンドロビン機能を使用する設定になっている場合、名前サーバのラウンドロビン拡張機能
が有効になっていない可能性もあります。名前サーバのラウンドロビン拡張機能の設定を確認してください。
この設定については、ドメインの名前サーバを使用している場合は「コンフィグレーション」→「11.1 Object Broker 設定項目・設定方法」を、ドメイン外の名前サーバを使用している場合は「オプション製品」→
「WebOTX Object Broker C++」→「WebOTX Object Broker 運用ガイド」→「1. 環境設定について」を参照してください。
リファレンスの登録が永続的となっていて、まだ一度も呼び出しに成功したことがないという場合は、単にリファレンス
登録を行っていない可能性があります。woiorinfo
で登録状況を確認するか、
リファレンス登録を再実行してみてください。
クライアント側で指定したタイマ(デフォルト30秒)の間に応答が返ってこない場合にNO_RESPONSE例外が返ります。 NO_RESPONSE及び無応答の場合は、APサーバでデッドロックやループ障害などがおきている可能性があります。
→APストールへの対応
→CPU使用率の過剰への対応
また、デッドロックなどで完全に処理が止まっていなくても、リクエスト量の増加による処理待ち時間増加や
APの修正による処理時間増加などによって遅延が起きている可能性もあります。
→オペレーション遅延への対応
→キュー滞留によるレスポンス遅延への対応
J2EEアプリケーションの場合、同一プロセスグループ上で動作する異なるアプリケーションアーカイブファイルに
含まれるアプリケーション間の呼び出しはリモート呼び出しとなり、別スレッドでの実行完了を待ちます。
このため、実行スレッド不足によるデッドロックが発生する可能性があります。
例えば、同一プロセスグループにwarとejb-jarでアーカイブされたアプリケーションがそれぞれ別々に配備され、
スレッド数の設定が1である場合にサーブレットからEJBを呼び出すと、空きスレッド待ちの状態となって
デッドロックが発生します。
プロセスグループのスレッド数を増やすことにより、スレッド数よりクライアントの同時接続数が少ない場合
はデッドロックは解消しますが、スレッド数以上の要求を受け付けたときはやはりデッドロックとなる可能性があります。
このような場合は呼び出し元と呼び出し先のアプリケーションをひとつのアプリケーションとしてアーカイブして
配備するか、別々のプロセスグループに配備するようにしてください。
リクエスト量の増加による処理待ち時間増加やAPの修正による処理時間増加などによって遅延が起きている可能性があります。
オペレーションの遅延は運用アシスタント機能により自動的に検出することができます。詳細は「TPモニタの運用操作 2.40 運用アシスタントに関する設定」を参照してください。
エラーの詳細は不明ながらもクライアントの利用者からエラーの報告を受けることは多々あります。可能であればトレースを
設定して再現させてください。トレースが取れない場合も、状況によってはある程度原因が絞り込める可能性があります。
・特定のオペレーションが常に失敗し、それ以外は成功する場合
成功するオペレーションがあるのでAPサーバへ到達するまでの設定に問題はなさそうです。名前サーバやAP実行基盤の起動状態
も問題ありません。但し名前サーバが正しく見られているものの肝心のリファレンスがない可能性があります。
woiorinfoで登録状況を確認するか、リファレンス登録を再実行してみてください。
一番可能性が高いのが特定のオペレーションを含むプロセスグループかアプリケーショングループが
障害状態(または単に起動してない)ケースです。
→ アプリケーショングループ未起動への対応
→ プロセスグループ未起動への対応
・特定のクライアントのみ常に失敗となる
特定のクライアントだけがまったくうまく行かない、成功することがない、という場合です。WebOTXのサーバではクライアント
の設定がありません。つまりクライアントのアドレスによってどうこうという処理がありません。このため特定のクライアント
のみ失敗するケースでサーバ要因の可能性は低く、クライアント側の設定に問題がある可能性が高いです。正常なクライアント
との間で環境の比較を行ってください。
・特定のオペレーションが成功したり失敗したりする
その特定のオペレーションに付与されたユーザデータの違いにより成功したり失敗したりしている可能性があります。
該当のプロセスグループで障害が起きていないか確認してください。ユーザデータを含めた電文長が制限を越えている
可能性も考えられます。制限の約10M(9999998byte)を越えていないか確認してください。
・一度失敗すると失敗し続け、プロセスグループの再起動で復旧する場合
プロセスグループの再起動にあたり、正常停止操作がタイムアウトし、強制停止操作でようやく停止できたという場合は、オペレーション
実行がいつまで終わらない状況になっていた可能性があります。システムトレース（運用編「ロギング」）に実行中だったオペレーション
の情報が残っているはずなので確認してください。