JRun4クラスタのハングアップ

IIS+JRun4の構成時TAMはステートレスジャンクションだった。
セッションを継続するためにはJRun4のアフィニティ機能が必須である。
JRun4のアフィニティ機能はスティッキーセッションと呼ばれている。

IISにJRun4のISAPIフィルターモジュールのDLLとして実装されている。
jrun.dll/jrun_iis6.dll/jrun_iis6_wildcard.dll
このISAPIのモジュールのことをコネクターと呼んでいる。

セッションの継続はJ2EEの仕様どおりJSESSIONIDのクッキー値を使う。
{jrun}/servers/{servername}/SERVER-INF/connector.properties
にサーバーのIDを持っている。
server.id=c830

セッションの割り振りのときに
JSESSIONID=c830xxxxxxxxxxxxxxxx
のクッキーの値がセットされる。

IISのJRun4コネクターはJSESSIONIDの値の先頭4文字を見て該当する
JRun4サーバに中継するのだ。

セッションオブジェクトをserializableにしておくと
in-memoryセッションレプリケーション機能を使うこともできる。

これがJRun4がよくハングアップした原因と思っている。
ユーザはIEを立ち上げてWeb上の共通メニューのURLを開く、
シングルサインオン機能ののTAMは
PD-ID=xxxx
の認証クッキーをブラウザにセットする。

共通メニューからウィンドウをポップアップさせてJRun4のアプリを開く
JRun4は
JSESSIONID=c830xxxxxxxxxxxxxxxx
をブラウザにセットし、２台のJRun4の間でメモリー間のレプリケーションをはじめる。

問題はJRun4のセッションがタイムアウトした時に発生する。
このブラウザの使い方では共通メニューのブラウザにJRun4のJSESSIONIDが残り続けてしまうのだ。
さらにJRun4のアプリにはクッキーを無効にするログオフ手順が無いことも原因の１つである。

何回もログインするのは面倒なので共通メニューを起動したままユーザはシステムを使い続ける。
JRun4のアプリを再び起動するとタイムアウトしたJSESSIONIDの値がIISに投げられる。
該当するセッションオブジェクトが存在しないのでJRun4はレプリケート先にセッションをさがしに行くのだ。

こんな理由で無効なセッションをレプリケート先にさがしにいくリクエストが大量に発生する。
レプリケータがパンクして２台ともJRun4がハングアップするのだ。

End of FILE.