On 02.09.2009 23:38, Jason Wright wrote: > I've an interesting situation with our application clusters. I am running > multiple applications for one of our websites. We don't share sessions > between the different servers; we use sticky sessions instead. Session > replication is difficult because of the large size of our users' sessions. > > We use applications A & B. I would like application A to run on servers 1 > and 2 and application B to run on servers 3 and 4. > > The user initially requests application A and receives a sticky session for > server 1. Later, the user requests application B. Since the sticky session > was set, server 1 is accessed, but application B is not found. If
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. > sticky_session_force is set, then another server is tried; however, the No, see above. No session info, then stickyness is never applied. If there were session info, then the force switch would work in the opposite way, namely if set to false, it will allow failover. Default is false. > sticky session will still be set to server 1 and the application B may not > use the same server. > > I've thought of 3 possible ways to solve this problem with a preference to > the one I don't know how to do yet. Not sure what the (real) problem is, likely you want both apps to be reachable under the same server name. > The first (my preference) is to be able to use multiple sticky sessions, one > for each application. This might involve multiple copies of modjk loaded by > tomcat with multiple workers.properties files, or something like that. I > would have no idea of how to do this. Does anyone know how to do this? No, this works out of the box. I assume there is no relation between the two apps A and B. Configute two lb workers, like lbA and lbB. One has member node1 and node 2, the other node3 and node4. Set the jvmRoute in server.xml of the four nodes to these names respectively. Finally add a JkMount /myappA|/* lbA JkMount /myappB|/* lbB That should be all that's needed. When testing, check the session cookies in order to understand what's going on. There are lots of Firefox plugins to look at cookies comfortably, like e.g. FireCookie. FireBug is also nice. > The second way of solving this problem is to use multiple copies of Tomcat > bound to different IP addresses with different configuration files. This > solution would be seen as subdomains to the user. > > The third way of solving this problem is to use multiple copies of Tomcat > bound to different ports (same IP address) with different configuration > files. This solution would have the same domain, but different port numbers. > > > I'm pretty sure that the second and third solutions would work, but I'm not > sure about the first solution. I've searched extensively and haven't found > anyone with the same problem. Has anyone on this list been in this situation > or know the best way to solve this problem? Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
