tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Vromant <anthony.vrom...@bull.net>
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 
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message