Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45883957.2000307@kippdata.de>
Date: Tue, 19 Dec 2006 20:11:19 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Smooth applications migration in a J2EE cluster [mod_jk]
References: <45759465.8060201@bull.net> <4575959A.70309@apache.org>
 <45759D39.8060608@kippdata.de>
 <45767DB3.4070206@bull.net>		 <4576A968.3040107@kippdata.de>
 <457933F5.10803@bull.net> <4582726B.6010606@bull.net>
 <4583F995.7060900@kippdata.de> <4587A2E2.5050402@bull.net>
In-Reply-To: <4587A2E2.5050402@bull.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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