tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Vromant <>
Subject Re: Smooth applications migration in a J2EE cluster [mod_jk]
Date Wed, 20 Dec 2006 15:04:16 GMT
Hi Rainer,

In my test case, i start only with 3 actives workers.
So i think you want me to make a graceful restart of apache in order to 
add the 3 stopped workers ?
Is this that ?
Anyhow, i understand that without changing route, this can be a good 

But about the invalidated session Valve :

If this Valve invalidates a cookie and redirects users to a login page, 
it is not transparent for the users.

Can we imagine that during an update, if this Valve is activated and 
used, mod_jk detects it (through the response sent by the valve) and 
sends the request to an active worker ?
It would be a kind of transparent fail-over implemented by mod_jk.


Rainer Jung wrote:
> 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:
> For additional commands, e-mail:

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

View raw message