Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of ellecer@gmail.com designates
 209.85.213.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EAB1641.9000608@christopherschultz.net>
References: 
 <CAPjZdoy+QrMQQMq3y+wDHDxZPUapbxPAdqG-7w8U1k6yVdjbmA@mail.gmail.com>
 <4EA91812.7030105@apache.org>
 <CAPjZdox=wjdyDQ=DPsLgJJz6X9FYn9bZ-iDi5sKZ1hwUGt9hmQ@mail.gmail.com>
 <4EAB1641.9000608@christopherschultz.net>
From: Ellecer Valencia <ellecer@gmail.com>
Date: Mon, 31 Oct 2011 14:38:34 +1100
Message-ID: 
 <CAPjZdowFv74XtvgvbX8aqCe2Hz5K5baEXkaNBMbhWtEuhiizKg@mail.gmail.com>
Subject: Re: Rollback in Tomcat7 under parallel deployment
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=UTF-8

Hi Chris,

But how would it cause an outage? ROOT##003 would not necessarily be
copied from the file ROOT##001.war

It'll be a separate deployment, but just using the same build that got
deployed as ROOT##001.

Whether ROOT##001 is marked for undeployment should not make a
difference to ROOT##003. They will "own" different sessions.

Ellecer


On Sat, Oct 29, 2011 at 7:53 AM, Christopher Schultz
<chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ellecer,
>
> On 10/27/2011 7:11 PM, Ellecer Valencia wrote:
>> On Thursday, October 27, 2011, Mark Thomas <markt@apache.org>
>> wrote:
>>> A better way to handle the rollback scenario is to deploy a copy
>>> of ROOT##001.war as ROOT#003.war.
>>
>> That's the first option we saw, but just wanted to confirm that
>> there wasn't another rollback feature similar to parallel
>> deployment. I guess in a rollback scenario it's probably more
>> prudent to just end those sessions since the app is broken anyway.
>> The idea of "parallel rollback" hurts my head just imagining how it
>> would be implemented! =)
>
> I might be worried that ROOT##001 had been marked for
> eventual-undeployment and you might find yourself in a situation where
> your "rollback" essentially causes an outage.
>
> Mark, can you confirm the behavior in this situation? The (brief)
> documentation says that the "latest version" will be used if a session
> does not yet exist. Is the "latest version" defined as the highest
> version number yet deployed (in which case the above scenario will
> occur) or is it defined as the highest version number currently deployed?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6rFkEACgkQ9CaO5/Lv0PBR9ACghJGnUy7tSYzmo7MJNA73eWsZ
> GYAAnR/7fvwFtzeFRcnhhouAW88VOrBX
> =zn6f
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

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