tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Vromant <anthony.vrom...@bull.net>
Subject Re: Smooth applications migration in a J2EE cluster [mod_jk]
Date Wed, 27 Dec 2006 09:22:51 GMT
Hi Rainer,

I wanted to know if you had had time to think on the subject of the 
invalidated session Valve ?

Other informations that you gave us before were very useful.
Thanks a lot.

Regards,
Anthony

Anthony Vromant wrote:
> 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 
> solution.
>
> 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.
>
> Regards,
> Anthony
>
> 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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>   
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message