gmt-24.net

mod_jkでlbワーカを使う場合、セッションによって振り分け先を固定化するためにsticky_sessionという属性が用意されている(デフォルトtrue)。実際のところ、どういう動きになるのかソースを追ってみた。

sticky_sessionパラメータを参照しているのは、jk/native/common/jk_lb_worker.cのJK_METHOD service()部分のここらへん。

    if (p->worker->sticky_session) {
        /* Use sessionid only if sticky_session is
         * defined for this load balancer
         */
        sessionid = get_sessionid(s, p->worker, l);
    }

get_sessionid()もjk_lb_worker.cで実装されていて、以下のようになっている。

    val = get_path_param(s, p->session_path);
    if (!val) {
        val = get_cookie(s, p->session_cookie);
    }

URLパスからsession_path入手を試み、ダメならsession_cookieから値を設定している。
この時点でURLパスに含まれるsession_path値のほうがsession_cookieよりも優先されることが判明。

ちなみにget_path_param()もget_cookie()もjk_lb_worker.cで実装されていて、get_path_param()のほうはURLパスからp->session_pathで始まる値の”=”以降、終端(?か;か\0)までを返すようになっている。get_cookie()も似たような処理なので割愛。

次にget_sessionid()で入手したsessionidは

rec = get_most_suitable_worker(s, p->worker, sessionid, p->states, l);

で一致するsessionidを探し、なければfind_best_worker()でワーカを決定するようになっている。

なんとなく動きはわかったものの、JSESSIONIDという文字列がどこにも出現しないので、今度はそちらを追いかけてみることに。
JSESSIONIDはjk/native/common/jk_global.hの中でJK_SESSION_IDENTIFIERとして定義されている。

JK_SESSION_IDENTIFIERを参照してるのはjk_lb_worker.cのjk_get_lb_session_cookie()呼び出し部分。

    strncpy(p->session_cookie,
            jk_get_lb_session_cookie(props, p->name, JK_SESSION_IDENTIFIER),
            JK_SHM_STR_SIZ);
    strncpy(p->session_path,
            jk_get_lb_session_path(props, p->name, JK_PATH_SESSION_IDENTIFIER),
            JK_SHM_STR_SIZ);

jk_get_lb_session_cookie()はjk/native/common/jk_util.cで定義されていて、JK_SESSION_IDENTIFIERはjk_map_get_string()にそのまま渡している。

jk_map_get_string()は、結局MAKE_WORKER_PARAM(SESSION_COOKIE_OF_WORKER)マクロでworker.ワーカ名.session_cookieの設定値(デフォルト”JSESSIONID”)を返すようになっていた。

jk_get_lb_session_path()もほぼ同じでMAKE_WORKER_PARAM(SESSION_PATH_OF_WORKER)によりworker.ワーカ名.session_path設定値(デフォルト”;jsessionid”)を返す。

結局のところ、こちらは両方ともworker.propertiesでの設定値かデフォルト値かを設定しているだけ。

ここで設定されたキー(p->session_path=”;jsessionid”かp->session_cookie=”JSESSIONID”)をベースに最初に出てきたget_most_suitable_worker()で振り分け先を決定している、ということになる。

mod_jkを使ってApacheとTomcatを連携される際、Tomcat側で処理させるURLパスをJkMountディレクティブで指定しますが、開発環境など変更が激しい環境ではこの定義変更にApache再起動が必要になってしまうので不便なときがあります。

httpd.conf

JkMount /jsp-examples/* ajp13
JkMount /servlets-examples/* ajp13

これをApache再起動なしで変更したい場合は、uriworkermap.propertiesを使って定義を外だしにしておくと便利です。

httpd.conf

JkMountFile conf/uriworkermap.properties 
JkMountFileReload 60 

uriworkermap.properties

/jsp-examples/*=ajp13
/servlets-examples/*=ajp13

こうしておくとuriworkermap.propertiesを書き換えた60秒後には変更が反映されることになります。
JkMountFileReloadが再読み込みの間隔で、デフォルトは60秒。0を指定すると無効化できます。
mod_jk 1.2.20以降で利用できます。

本番では無用なミスを避けるためにも、JkMountを使うか、JkMountFileReload 0にしておくことをお勧めしますが 😛

TomcatのウェブフロントエンドにApacheを使っている場合、Tomcatの出力結果に対してApacheのSSI処理を施すことができます(Tomcatの、ではなく)。

例えば

JkMount /jsp-examples/* ajp13
<Location /jsp-examples>
  SetOutputFilter INCLUDES
</Location>

とした場合、jsp-examplpes配下のjspファイルにSSIを仕込むことができます。
AddOutputFilterだとファイル拡張子の指定が必要になってしまうので、SetOutputFilterを使うのがポイントです。試してませんがAddOutputFilterByTypeでも大丈夫かも知れません。

以下、jsp-examples/snp/snoop.jspに仕込んで試したコードです。

$ diff -u snoop.jsp.orig snoop.jsp
--- snoop.jsp.orig      2007-03-06 00:26:05.000000000 +0900
+++ snoop.jsp   2007-05-29 17:02:50.000000000 +0900
@@ -52,5 +52,9 @@
 The browser you are using is <% out.print(util.HTMLFilter.filter(request.getHeader("User-Agent"))); %>
 <hr>
 </font>
+<pre>
+<!--#printenv -->
+</pre>
 </body>
+<!--#include virtual="/footer.html" -->
 </html>

virtualの場合ApacheのDocumentRootからのパスになります。fileのときは試してません 😛