On 03.09.2009 23:31, Christopher Schultz wrote: > Rainer, > > On 9/3/2009 4:36 AM, Rainer Jung wrote: >> No. > >> The stickyness doesn't magically track your clients. If the client sends >> a session information, and the session information contains a route tag >> (a suffix .nodeX, where nodeX is set by the jvmRoute attribute in >> server.xml), then mod_jk looks for a balancer member named nodeX. > >> When/How does the client send session information? Either as a cookie >> named JSESSIONID, or via URL encoding ...;jsessionid=....nodeX > >> By default, application A with context name /myappA uses cookies and >> only sends cookies if the request goes to something in /myappA. So a >> request for application B with context /myappB doesn't include the >> cookie for A and the load balancer is free to distribute the request to >> any node. > > One caveat: if you have a ROOT context along with other non-ROOT > contexts, things can get tricky because you'll get cookies like: > > name=JSESSIONID, path=/, expires=..., value=... > name=JSESSIONID, path=/foo, expires=..., value=... > name=JSESSIONID, path=/bar, expires=..., value=... > > Whenever a client browses to webapps found on / and /foo, the requests > to /foo will get TWO cookies, and confusion may occur (I'm not sure what > mod_jk will do in this situation... Rainer?).
Not sure either :( Even if I looked at the code now, I wouldn't take it for granted, that the behaviour can't change. Actually I'm not even sure what the browser is supposed to send (the same cookie multiple times, or only the one with the longest path match). > My advice is to avoid "nesting" webapp URL spaces. I accidentally did > this for years until I discovered the problem when adding > sessionid-passthrough to another webapp (where the session id couldn't > be validated before being passed-through) and everything went crazy. > When I separated the URL spaces, everything was fine. > > Hope that helps, > -chris Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
