GO-Global for Windows

[番号]
技術ノート KGTN 2010041401

[現象]
ユーザのログオフ操作と強制ログオフコマンド GMCheckRaw -kn all が同じタイミングで行われた時，セッションが終了しないことがある．

[説明]
ユーザのログオフ操作と強制ログオフコマンドが同じタイミングで行われた時，GG内部の通信路の排他制御の問題等により，セッションが終了しないことが確認されております．ユーザ側ではログオフ操作が行われておりますので，見かけ上は正常に操作が終了します．強制ログオフコマンド側では処理の完了待ちの状態になりますが， GMCheckRaw はマルチスレッドで実装されておりますので，30秒後にタイムアウトが発生しコマンドが終了します．この状態でセッションは終了せずに残りますが，それぞれの要求がクリアされますので，この直後に改めて強制ログオフコマンド GMCheckRaw -kn all を実行することで，残ったセッションを終了させることが出来ます．

補足１
本件はGraphOn社に報告済 （CASE#9006） で，GraphOn社ではAPSログおよびADPlusによるダンプファイルをもとに解析作業を進めております．

補足２
「本現象発生時に GMCheckRaw でリトライ出来ないか？」 というお問い合せについて … 本現象発生時は，GMCheckRaw から見た場合，セッションの終了要求がいつまでも完了しない状態にあり， GMCheckRaw の別スレッドでこの状態を検知し，タイムアウトとしてプログラムを終了させております．従って， GMCheckRaw 内部でリトライ機能を追加実装することは技術的に困難で，リトライ機能を実装するとすれば，GMCheckRaw の上位にプログラムを作成し，そのプログラムがタイムアウトかどうかを判断し，タイムアウトであれば GMCheckRaw を新たに呼び出してリトライすることになります．一般的な運用を考えた場合，GMCheckRaw を呼び出すスクリプトがあると思われますので，技術的にはそのスクリプトでリトライする方が単純 （上位に新たなプロセスが増えない） で，かつ管理がし易いのではないかと考えます．

補足３
GMCheckRaw 内部でデッドロックしている可能性はないのか？ … APSへの要求は全て同期型のAPIで行うようになっており，本件は SMI_DestroySession というセッションを切断するAPIの応答待ちの状態にあります．従って， GMCheckRaw 内部でのデッドロックではありません．

APIの応答待ちの通信路を一旦切って，改めて通信路を作成して要求を再送することは出来ないのか？ … GraphOn社が提供するAPI （SDK） は，１つのプロセスから１度だけ通信路を作成出来るようになっております．従って，このような方法で要求を再送することは出来ません．