Hi Anthony,
Anthony Vromant schrieb:
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 ?
Ah OK, yes I agree. You could use a filter (or Valve) to redirect
requests with an invalid session to the login page without URL encoding
and invalidating the cookie. That way you would destroy the invalid
binding to this node.
If we would try to do that with mod_jk directly, mod_jk would need to
have a shadow copy of the session list, something which doesn't sound
right. OK, mod_jk could ask tomcat about the session, but we can also
simply forward and let the node delete the binding.
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 ?
With sets I simply mean sets :) Somehow you configure each worker twice,
but with different names. Domains come into play, to define failover
rules between the workers. Failover should not hapen between the sets.
So each set will belong to one domain. A mod_jk domain is nothing else,
than failover information (try another worker in the same domain first,
before trying any other worker).
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.
Active:
worker1a : route = worker1a, domain=domain1
worker2a : route = worker2a, domain=domain1
worker3a : route = worker3a, domain=domain1
Stopped:
worker1b : route = worker1b, domain=domain2
worker2b : route = worker2b, domain=domain2
worker3b : route = worker3b, domain=domain2
Sticky session = true
Then you would follow the above steps.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
