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]
