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()で振り分け先を決定している、ということになる。
