Hi, Brian,
I think you are right! It exist no reason why we only change the
session id at cookie session id case!
Hmm, I thing my test env and customer app are cookie based :-( Then
I later not made it ready to support also request session ids.
I find a easy fix to getting it work. The enhancement include at
tomat 5.5.17 release.
Many thanks to reporting it,
Peter
Am 27.03.2006 um 22:07 schrieb Brian Stansberry:
Hi,
I noticed that in o.a.c.cluster.session.JvmRouteBinderValve there is a
block of code
that basically prevents changing a session's jvmRoute if URL
rewriting is used:
if (request.isRequestedSessionIdFromURL
()) {
if (log.isDebugEnabled())
log.debug(sm.getString("jvmRoute.skipURLSessionIDs"));
} else {
handleJvmRoute( request, response,session.getIdInternal(),
jvmRoute);
}
This basically means that if cookies are disabled and a session
fails over, the
jvmRoute portion of the session id won't be changed. AIUI, if this
isn't changed,
thereafter mod_jk will not pin the session to any server. That's a
pretty big
limitation to distributed sessions.
In JBoss clustering we have a similar valve that has pretty much the
same limitation.
Does anyone know any reason for this limitation? If cookies are
disabled, we
of course shouldn't emit a cookie, but why not change the id of the
session object?
Looking at how Response.encodeURL works, it uses the session object's
id when encoding,
so if we change this field, any subsequently emitted URLs should have
the proper id
with the new jvmRoute. This valve is invoked before the request enters
the webapp, so
the id change will take place before the webapp writes any URLs.
Thanks!
Brian Stansberry
Lead, AS Clustering
JBoss, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
