tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Vromant <>
Subject Re: Smooth applications migration in a J2EE cluster [mod_jk]
Date Tue, 19 Dec 2006 08:29:22 GMT
Hi Rainer,

Thanks for this explanations. I'm going to try to give you more 
technical informations.

Rainer Jung wrote:
> Hi,
> yes I looked at the animation. Although I must confess, that I don't get
> much out of it technically. What's the reason for the need to test
> session validity? Is it needed to find out, if a node already got
> upgraded to a new app version, so the session needs to get routed to a
> node, still running the old app version? That's what I expect, since you
> introduced worker "versions" (one could also name it "generation").
You're right, the animation doesn't show the technical part of prototype 
at all.

Here is the explanation about the session validity checking :

This test aims to have users with expired sessions and URL encoded 
(or long running browsers with cookies cached) redirected to a node
hosting the new version of the application.
If this test is not done during the update, these users will start a new 
session on a
node hosting the old version of application (and so, perhaps just before 
the stop of these node).
Do you agree with this ?
> OK, we are only talking about cluster (in the sense of session
> replication) and I assume, that we are interested in the case of an
> application update, which is non-compatible concerning sessions and/or
> URL structure.
Exactly. And beyond than sessions or URL structure, we can address the 
ejb  application update (stateful), the data models update (database), 
or even the update of the application server itself.
> At the moment, sessions will be routed according to the routing suffix
> in their id. Sessions which failed over can be rewritten (get another
> routing suffix) by a Valve and thus be bound to another (surviving)
> node. But sessions which have been idle will still be called with the
> old suffix by the browser the next time they are used. If the node got
> an update in the meantime, they will get routed to an incompatible node
> and throw an error.
> As a first simple workaround one could use two sets of workers and of
> target (tomcat) nodes. One set would be stopped, on active at a time.
> The two sets use different jvmRoutes. Replication is not done across set
> boundaries.
When you say "2 sets of workers", you mean using the notion of domains ?
> You upgrade the stopped set, test it via an internal connector/vhost and
> then change its activation to active. Also you change the activation of
> the formerly active set to disabled. New sessions will go to the updated
> set, old sessions will still go to the unchanged set. Invalid sessions
> will need to redirect to a start page without session information. After
> some (depending on session use time) you stop the disabled set, to
> prevent people with URL encoded bookmarks (or long running browsers with
> cookies cached) to still reach the old version.
One of our objective is to use as much as possible mod_jk's capabilities.
So our prototype is based on using of these features :
- disabling a worker
- session rewriting (with a Valve)
- route modification

I've tried to pass the scenario you explain here, and i had a problem :

Here's my mod_jk (1.2.20) configuration :
worker1 : route = domain1.worker1, domain=domain1
worker2 : route = domain1.worker2, domain=domain1
worker3 : route = domain1.worker3, domain=domain1
Sticky session = true

And here's the test :
1/ Session initialization on worker1 : JSESSIONID.domain1.worker1
2/ Stop worker1
3/ Upgrade worker1
4/ Change route/domain of worker1 : route = domain2.worker1, domain=domain2
5/ At the same time : Active worker1 and disable worker 2 and 3
6/ Refresh on JSESSIONID.domain1.worker1
  -> The request still access on worker1

Whereas we want her to be routed to the
old version of application (so workers 2 or 3).
For the requests initialization on worker 2 or 3, it's ok.

Perhaps I missed something.

I'm actually writing some sequence diagrams to formalize all this uses
Do you have any ideas about that ?
> Now this scenario does not really help, if you want to do *many*
> updates. It granularity is somehow to coarse. To make it work more
> smoothly, we would need an automatic way of managing jvmRoute,
> worker.route and worker.domain consistently during application upgrade
> (increasing generation counter which gets appended to the route). It
> looks like you did something like that?
We have the same point of view on the granularity of a migration.
Actually, there's a lot of commands to make in an update, and a lot of
those may be transparent to the users.
> Somehow I don't really see the need of checking the validity of a
> session by mod_jk. We only need to know, which version of the app the
> session belongs to, and which version of the app the various workers
> talk to. This could be done by a generation counter in jvmRoute and all
> routing related strings in mod_jk.
Yes, i understand that we could manage the link session/version with the
It's what we aim to do.
> In your original mail, you talked about additional hooks you would need
> inside mod_jk. What would that be?
The hook was made in the first version of the prototype (mod_jk 1.2.15). 
We're now changing a lot of things..
> Regards,
> Rainer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message