-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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?). 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqgNaEACgkQ9CaO5/Lv0PC7nQCgtvFONQbvlmx7zrz+rmKaFVdI PcgAnjDcnYoWXNmsMW8bIE58tSnUBFuG =9T+N -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
