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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
