tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [Tomcat] Looking for JSESSIONID in Tomcat
Date Fri, 28 Jul 2006 16:52:45 GMT

> My current work relates to a context where we want to update a J2EE application
> without stopping it.

Well, you'll certainly have to stop the application at some point. I
assume you mean that you don't want a complete cut-over to the new
system: you need a phased cut-over to assure continuous uptime.

The general process is to do the following:

1. Wean users off some of your production servers. This can usually
   be done by removing those servers from the load balancing or DNS
2. Wait for #1 to complete (usually a period of a few hours or even a
   day or so).
3. Bring your new servers online, and switch the load balancing or DNS
   rotation completely over to the new servers. Allow your load balancer
   to continue to route "old" sessions to the servers running the old
4. Wait for all sessions to die on the "old" servers.
5. Upgrade the remaining servers and reset your load balancer to use
   all servers.

> As a result we have to separate both, this separation is possible because of the
> use of the cookie JSESSIONID.
> I have modified a load balancer (mod_jk) to do this, but when the load balancer
> receives a HTTP request it can't know whether the session is always available
> or not (Indeed a session may expire and the cookie bind to it becomes invalid).
> So I want to know if it is possible for an external program to test if a session
> exists on the Tomcat server? Or what is the name of the structure/object
> managing Tomcat's cookies in a cluster? Or how does Tomcat make to know if
> cookie is valid?

There is at least a cheap way of doing this: make a request to the
server to some protected URL, and include the session id as a parameter
instead of a cookie. Something like this:


If you get a challenge for a login, then the session does not exist.

This doesn't sound like a really good solution, though. Your better bet
is to use a load balancer that can set an app server affinity and keep
track of that (usually using a cookie). Then, you blindly forward
requests to the server to which the session was previously assigned.


View raw message