DiskPageStoreクラスタ対応機能検証

さて、クラスタリング対応との事で、検証してみた。

SessionStoreがクラスタ対応ならAPサーバにクラスタ機能なくてもクラスタリングできるってことっすよね？？？？

はい、検証内容は以下。結果からいうとダメ。

WebApplicationの設定

@override
protected ISessionStore newSessionStore() {
	return new SecondLevelCacheSessionStore(this, new DiskPageStore(new
File("c:\\temp"), 10, 10, 10));
}

上記設定でJettyを80番と81番で起動し、サブミット等でURLにwicket:interface
がついたところで、ポートのみ書き換える。

結果、PageExpiredエラーとなりました。

c:\tempをウォッチするとjettyがセットしたクッキーのjsessionidの値でフォルダができているんで、できそうなもんですが、Jettyとしてはjsessionidはあるけど、Sessionは作成してないからセッションIDも渡せないということで、まぁ考えてみれば普通の話。

要するにblogにあった「transparent clustering support」とは

「クラスタ対応」かつ「DBやファイルへの永続化の無い」APサーバにおいて、Wicket使用時の最大の心配事であるメモリ消費量を抑える機能。

ということのようです。（認識違いがあればDISってください）
SecondLevelCacheSessionStore
が何故SecondLevelなのかは今回の調査が正しければ、
「HTTPSessionの補助機能でしか無いから」
っぽいですね。

あ、見落としがあるかもしれませんが、永続化セッションの掃除機能も見あたりませんでした。
作りによってはMB単位のセッションもできるってのに、しばらく放置するとえらいことになりそうな。

大きな進歩のようななんだか今一歩のような…

WicketでセッションIDの管理もやって、APサーバのクラスタ対応まったく不要で、DBへの永続化機能があれば文句ないんですけどねー。あ、前回書いてあった自分で作れって事なわけだ。うーん。

メモリ上のセッション複製によるクラスタ機能しかないAPサーバの場合には役に立ちそう。
できたばっかりなのでちょっと不安だけど…