You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ellecer Valencia <el...@gmail.com> on 2011/10/27 08:41:44 UTC
Rollback in Tomcat7 under parallel deployment
Hi,
If I'm using parallel deployment in Tomcat 7, and now have 2 webapps
/webapps/ROOT##001.war
/webapps/ROOT##002.war
and then get problems in the new version and want to rollback to ROOT##001.war.
If I delete the more recent version by doing
rm /tomcat/webapps/ROOT##002.war
What happens to the sessions that are being serviced by #002 once the
file is removed? Will #002 still be around to service these sessions
expire, or does Tomcat remove all these sessions instantly?
Also, what happens if ROOT##001 and ##002 have the same log4j configs
and are writing to the same log file?? How have people handled this
situation?
thanks for you help,
Ellecer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Posted by Pid <pi...@pidster.com>.
On 29/10/2011 12:41, chris derham wrote:
>>
>>> Also, what happens if ROOT##001 and ##002 have the same log4j configs
>>> and are writing to the same log file?? How have people handled this
>>> situation?
>>
>> You'll certainly end up with both apps writing to the same file. Whether
>> or not that is a problem will depend on exactly how you have configured
>> logging.
>>
>
> Is it possible to pick up the name of the war file (or version number) so
> that you can log to different files? So instead of
>
> ${catalina.base}\logs\myapp.txt
>
> I could use
>
> ${catalina.base}\logs\myapp-${applicationName}.txt
>
> say ${applicationName} which would be replaced with "ROOT##001", making the
> log file
>
> <catalina_base>\logs\myapp-ROOT##001.log?
>
> Basically I am trying to ask does such a variable exist, and if so what is
> its name?
The catalina.base variable works because it's a system property.
There's no applicationName variable.
p
--
[key:62590808]
Re: Rollback in Tomcat7 under parallel deployment
Posted by chris derham <ch...@derham.me.uk>.
>
> > Also, what happens if ROOT##001 and ##002 have the same log4j configs
> > and are writing to the same log file?? How have people handled this
> > situation?
>
> You'll certainly end up with both apps writing to the same file. Whether
> or not that is a problem will depend on exactly how you have configured
> logging.
>
Is it possible to pick up the name of the war file (or version number) so
that you can log to different files? So instead of
${catalina.base}\logs\myapp.txt
I could use
${catalina.base}\logs\myapp-${applicationName}.txt
say ${applicationName} which would be replaced with "ROOT##001", making the
log file
<catalina_base>\logs\myapp-ROOT##001.log?
Basically I am trying to ask does such a variable exist, and if so what is
its name?
Thanks
Chris
Re: Rollback in Tomcat7 under parallel deployment
Posted by Ellecer Valencia <el...@gmail.com>.
Ah yes. Thanks Chuck. That makes more sense. =)
On Mon, Oct 31, 2011 at 3:04 PM, Caldarale, Charles R
<Ch...@unisys.com> wrote:
>> From: Ellecer Valencia [mailto:ellecer@gmail.com]
>> Subject: Re: Rollback in Tomcat7 under parallel deployment
>
>> But how would it cause an outage? ROOT##003 would not necessarily be
>> copied from the file ROOT##001.war
>
> I believe Chris was referring to your originally stated tactic of just undeploying ROOT##002, rather than deploying a third version identical to the first.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Rollback in Tomcat7 under parallel deployment
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ellecer Valencia [mailto:ellecer@gmail.com]
> Subject: Re: Rollback in Tomcat7 under parallel deployment
> But how would it cause an outage? ROOT##003 would not necessarily be
> copied from the file ROOT##001.war
I believe Chris was referring to your originally stated tactic of just undeploying ROOT##002, rather than deploying a third version identical to the first.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Rollback in Tomcat7 under parallel deployment
Posted by Ellecer Valencia <el...@gmail.com>.
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
<ch...@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 <ma...@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
Re: Rollback in Tomcat7 under parallel deployment
Posted by Mark Thomas <ma...@apache.org>.
On 31/10/2011 20:22, Konstantin Kolinko wrote:
> 2011/11/1 Christopher Schultz <ch...@christopherschultz.net>:
>> I'm having trouble locating the code that auto-undeploys old versions
>> when all sessions have expired.
>
> There is no such code in Tomcat.
>
> You will see in the manager app that the counter of sessions is zero,
> but there is no such feature as automatic undeployment here.
That feature was proposed as a possible extension to parallel deployment
but never implemented. I'm not sure how easy it would be. Thinking about
it (for about 30s) the background process for a host could check for
contexts where session count is zero and there is a higher version
available. If it finds such a Context it could then undeploy it. I'd
want to make sure behaviour configurable though.
If anyone would like to take a stab at writing a patch to do this then
I'd be happy to provide pointers if necessary.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/11/1 Christopher Schultz <ch...@christopherschultz.net>:
> I'm having trouble locating the code that auto-undeploys old versions
> when all sessions have expired.
There is no such code in Tomcat.
You will see in the manager app that the counter of sessions is zero,
but there is no such feature as automatic undeployment here.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 10/28/2011 5:20 PM, Mark Thomas wrote:
> And the code says...?
Knowing that you'd say that, I had started looking for the code.
Unfortunately it's hard to search through 1200 source files for the
place where a Context is instantiated using reflection.
After lots of grepping and reading, I find myself back in the Mapper:
the road to which all things lead in Tomcat :)
For the edification of others, my reading of the code says that
undeploying a "broken" higher-version numbered context will work
properly, as the Mapper keeps the versioned contexts in order by
version and appears to search the list each time.
I'm having trouble locating the code that auto-undeploys old versions
when all sessions have expired. Mark, can you point me in the right
direction? I don't mind reading code *at all*, but I'm not familiar
enough with Tomcat's internals, yet, to know where to start.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6vApYACgkQ9CaO5/Lv0PDiKACbBlItt5Kz9rEQCXFBlbO9r2ts
KgQAoIScwefOmCIpsl+ZrsqQOveFkXZE
=ey3Y
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Posted by Mark Thomas <ma...@apache.org>.
On 28/10/2011 21:53, Christopher Schultz wrote:
> Ellecer,
>
> On 10/27/2011 7:11 PM, Ellecer Valencia wrote:
>> On Thursday, October 27, 2011, Mark Thomas <ma...@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?
And the code says...?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ellecer,
On 10/27/2011 7:11 PM, Ellecer Valencia wrote:
> On Thursday, October 27, 2011, Mark Thomas <ma...@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
Re: Rollback in Tomcat7 under parallel deployment
Posted by Ellecer Valencia <el...@gmail.com>.
On Thursday, October 27, 2011, Mark Thomas <ma...@apache.org> wrote:
>> Also, what happens if ROOT##001 and ##002 have the same log4j configs
>> and are writing to the same log file?? How have people handled this
>> situation?
>
> You'll certainly end up with both apps writing to the same file. Whether
> or not that is a problem will depend on exactly how you have configured
> logging. See [1] for other things to think about.
Looks like it's something that shouldn't be allowed to occur, at least under
log4j.
http://logging.apache.org/log4j/1.2/manual.html
"... image of the log4j environment will act independetly and without any
mutual synchronization. For example, FileAppenders defined exactly the same
way in multiple web-application configurations will all attempt to write the
same file. The results are likely to be less than satisfactory. You must
make sure that log4j configurations of different web-applications do not use
the same underlying system resource."
Logback supports writing to the same file, but at the cost of 3x slower
performance:
http://logback.qos.ch/manual/appenders.html#prudent
But that entails even more changes in our code, so we'll have to have a
workaround. (i guess we could replace log4j.jar with log4j-over-slf4j.jar
then use logback! http://www.slf4j.org/legacy.html)
>> thanks for you help,
>
> 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! =)
Ellecer
>
> Mark
>
> [1] http://java-monitor.com/forum/showthread.php?t=1288
Re: Tomcat 6 & 7 Logging to rsyslog
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
On 10/27/2011 7:58 PM, John Schwartzman wrote:
> Can anyone point me to documentation concerning logging of
> authentication information (login, logout, lockout) to a remote
> syslog in Tomcat 6 & 7?
1. Don't hijack threads.
2. Don't post twice.
3. Don't hijack the same thread twice.
4. Read the documentation on logging.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6rFoEACgkQ9CaO5/Lv0PDBAACgmRkSIaBZF/yf8Ij2i5SC6Zkg
tbAAnA6QVMEYx0PG9eM/s6buOq5EohYl
=1RHi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Tomcat 6 & 7 Logging to rsyslog
Posted by John Schwartzman <Jo...@ForteSystem.com>.
Can anyone point me to documentation concerning logging of authentication
information (login, logout, lockout) to a remote syslog in Tomcat 6 & 7?
Many thanks!
--
John Schwartzman
Forte Systems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Tomcat 6 & 7 logging to rsyslog
Posted by John Schwartzman <Jo...@ForteSystem.com>.
Can anyone point me to some documentation about logging authentication
information (login, logout, lockout) to a remote syslog in Tomcat 6 & 7?
Many thanks!
--
John Schwartzman
Forte Systems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Posted by Mark Thomas <ma...@apache.org>.
On 27/10/2011 07:41, Ellecer Valencia wrote:
> Hi,
>
> If I'm using parallel deployment in Tomcat 7, and now have 2 webapps
>
> /webapps/ROOT##001.war
> /webapps/ROOT##002.war
>
> and then get problems in the new version and want to rollback to ROOT##001.war.
>
> If I delete the more recent version by doing
>
> rm /tomcat/webapps/ROOT##002.war
>
> What happens to the sessions that are being serviced by #002 once the
> file is removed?
They will be lost.
> Will #002 still be around to service these sessions
> expire, or does Tomcat remove all these sessions instantly?
Instantly.
> Also, what happens if ROOT##001 and ##002 have the same log4j configs
> and are writing to the same log file?? How have people handled this
> situation?
You'll certainly end up with both apps writing to the same file. Whether
or not that is a problem will depend on exactly how you have configured
logging. See [1] for other things to think about.
> thanks for you help,
A better way to handle the rollback scenario is to deploy a copy of
ROOT##001.war as ROOT#003.war.
Mark
[1] http://java-monitor.com/forum/showthread.php?t=1288
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org