Thomas, > 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 rotation. 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 version. 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: http://your.server/protected/url;jsessionid=[SESSIONID] 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. -chris
signature.asc
Description: OpenPGP digital signature
