I don't fully agree: we use F5 too, but:
1) I know many commercial sites (in germany), which do not use Cookies (privacy reasons).
2) IP based stickyness does not work very well. In many scenarios you will only be able to correctly route "most" of your clients. If you rely on exact routing, IP-based will not suffice.
3) These are the reasons why I assume, that all balancers will support routing decisions based on the jsessionid in the URI. So they already have to support extracting routing information from the session id string.
So using the same jessionid string in the standard cookie will work in most (all ?) situations / for most products.
Example: mod_jk does it like that:
/* Retrieve session id from the cookie or the parameter */
static char *get_sessionid(jk_ws_service_t *s)
{
char *val;
val = get_path_param(s, JK_PATH_SESSION_IDENTIFIER);
if (!val) {
val = get_cookie(s, JK_SESSION_IDENTIFIER);
}
return val;
}
and after that it does no longer matter, where the info comes from.
On the other hand: what's wrong about embedding the jmvRoute as a suffix in the session id?
Rainer
Filip Hanik - Dev wrote:
its not at all that complicated. This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances. B) if a cookie is not supported, it does a calculation based on the IP address, and stays sticky that way.
No need to exchange any info in this scenario and very straight forward, and never goes wrong. The only time it goes wrong is for AOL users who can change gateway between HTTP and HTTPS
Filip
----- Original Message ----- From: "Rainer Jung" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org> Sent: Tuesday, February 08, 2005 10:39 AM Subject: Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is used to enable routing decisions by balancing components. All these components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include the jvmRoute in the jsessionid, since the jsessionid is standardized, so all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to have the same value. They are sort of two different ways to transport the same session information. So most balancer providers implement the routing decision features the same way, independant of the source of the session string.
Splitting the jvmRoute from the session id in the cookie case will most likely make the situation for all implementers of balancers more complex and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way, distributed applications exchange routing information with the clients/balancers. As long as that's not the case it is very likely, that jvmRoute as a suffix of the session id has much better support from balancer providers.
Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it for the cluster stuff
Filip
----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org> Sent: Monday, February 07, 2005 11:34 AM Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@ session.setValid(true); session.setCreationTime(System.currentTimeMillis()); session.setMaxInactiveInterval(this.maxInactiveInterval); - String sessionId = generateSessionId(); + if (sessionId == null) { + sessionId = generateSessionId(); + }
I just noticed my patch needs something for jvmRoute handling (basically, the session id which is recieved must be edited for the right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which would be a lot cleaner ? Was this ever considered ?
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
