tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: mod jk - multiple applications, different server clusers, sticky sessions
Date Thu, 03 Sep 2009 08:36:23 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message