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 17:09:11 GMT

The scenario you explained me doesn't work in my env. I'm trying to find 
out the reasons below :

Here is the code :

jk_lb_worker.c : "find_bysession_route()"

candidate = find_by_session(p, name, l);

   if (!candidate) {
       uses_domain = 1;
       candidate = find_best_bydomain(p, name, l);

If route was changed on a worker, "find_by_session()" method can't find 
a good worker (and thus its domain).

It seems to me strange in this case, to call "find_best_bydomain()" 
method with a route in parameter whereas a domain name is expected  ?

With the current code, when a route is modified (!candidate), domain 
affinity doesn't work anymore for the old active session related to the 
changed worker ?
Is it a normal behavior according to you ?

The JSESSIONID only knows the route, but not the domain and the code 
have to cope with this miss.
By the way, I've also tried to use routes with a period like 
'domain.worker', but it changes nothing.


Anthony Vromant wrote:
> 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 
> bookmarks
> (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
> cases.
> 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
> jvmRoute.
> 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
> Regards,
> Anthony
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message