Hi Jan,
glassfish_at_javadesktop.org wrote:
> OK, I found some useful info at:
>
> http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-valve.html
>
> which mentions:
>
> In case of a mod_jk failover, the JvmRouteBinderValve will replace the
> jvmWorker attribute in the session Id, to make future requests stick
> to this node. If you want failback capability, don't enable this
> valve, but if you want your failover to stick, and for mod_jk not to
> have to keep probing the node that went down, you use this valve.
>
> I've checked the source code of the
>
> createSession(String sessionId)
>
> method of org/apache/catalina/session/ManagerBase in Tomcat 6, and found
> this:
>
> if (sessionId == null) {
> sessionId = generateSessionId();
> // FIXME WHy we need no duplication check?
> /*
> synchronized (sessions) {
> while (sessions.get(sessionId) != null) { // Guarantee
> // uniqueness
> duplicates++;
> sessionId = generateSessionId();
> }
> }
> */
>
> // FIXME: Code to be used in case route replacement is needed
> /*
> } else {
> String jvmRoute = getJvmRoute();
> if (getJvmRoute() != null) {
> String requestJvmRoute = null;
> int index = sessionId.indexOf(".");
> if (index > 0) {
> requestJvmRoute = sessionId
> .substring(index + 1, sessionId.length());
> }
> if (requestJvmRoute != null && !requestJvmRoute.equals(jvmRoute)) {
> sessionId = sessionId.substring(0, index) + "." + jvmRoute;
> }
> }
> */
> }
>
> Looks like this code used to be responsible for updating the jvmRoute of a JSESSIONID to point to the new instance after a failover, so that the session would remain sticky to this new instance on subsequent requests.
>
> I guess this functionality is now handled by the JvmRouteBinderValve described above.
>
> I'm afraid that even if we added a jvmRoute to a JSESSIONID in GlassFish under certain conditions, this would not be of much use unless we also supported the entire org.apache.catalina.ha package and its cluster related valves (including the valve mentioned above), which would be a challenge by itself, since the valve interface in GlassFish differs from that in Tomcat.
>
I think we need to focus on 5.0.x, not 5.5/6 where the cluster code was
introduced....Need to refresh our memory with 5.0.x :-)
A+
-- Jeanfrancois
> Notice that GlassFish lets you configure your own sessionId generation algorithm, specified as the value of the session-id-generator-classname attribute of the <manager-properties> element in domain.xml. The specified class must implement the com.sun.enterprise.util.uuid.UuidGenerator interface. Theoretically, you could have your sessionId generation algorithm piggyback on the default GlassFish sessionId generation impl and append the jvmRoute to the result, if needed.
>
>
> Jan
> [Message sent by forum member 'jluehe' (jluehe)]
>
> http://forums.java.net/jive/thread.jspa?messageID=242022
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>