tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Smooth applications migration in a J2EE cluster [mod_jk]
Date Sat, 16 Dec 2006 13:50:13 GMT

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").

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.

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

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.

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?

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.

In your original mail, you talked about additional hooks you would need
inside mod_jk. What would that be?



Anthony Vromant schrieb:
> Hi all,
> I would like to know if you had time to look at the demonstration of our
> prototype.
> We are very interested to get your feelings about that.
> Do you have ideas about our problem of testing the validity of a user
> session within mod_jk ?
> We're thinking about a mechanism relying on the JMX-Adaptor of Tomcat
> that mod_jk can
> invoke through the AJP interface. What's your opinion ?
> Thanks.
> Regards
> Anthony Vromant
> Anthony Vromant wrote:
>> Hi Rainer,
>> First of all, thank you for these informations.
>> Here is the HTTP link for the Flash demonstration of our prototype :
>> I am looking at the new features provided by mod_jk 1.2.20, the
>> dynamic configuration reloading is quite interesting.
>> We are going to bring our prototype to this new version.
>> In our prototype, when a new request is coming with a JSESSIONID
>> cookie, a request is sent to the worker (tomcat) for checking the
>> validity (we need to know whether the session is still alive).
>> Currently, the HTTP protocol is used for invoking tomcat rather than
>> AJP. The control at the tomcat side is done through an internal
>> servlet which accesses the MBean manager for getting the current
>> sessions list.
>> Do you have any suggestion for improving that ?
>> Regards,
>> Anthony
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message