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.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EA91812.7030105@apache.org>
References: 
 <CAPjZdoy+QrMQQMq3y+wDHDxZPUapbxPAdqG-7w8U1k6yVdjbmA@mail.gmail.com>
 <4EA91812.7030105@apache.org>
From: Ellecer Valencia <ellecer@gmail.com>
Date: Fri, 28 Oct 2011 10:11:38 +1100
Message-ID: 
 <CAPjZdox=wjdyDQ=DPsLgJJz6X9FYn9bZ-iDi5sKZ1hwUGt9hmQ@mail.gmail.com>
Subject: Re: Rollback in Tomcat7 under parallel deployment
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=e89a8f646acf45f63604b04fe6bd

--e89a8f646acf45f63604b04fe6bd
Content-Type: text/plain; charset=UTF-8

On Thursday, October 27, 2011, Mark Thomas <markt@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

--e89a8f646acf45f63604b04fe6bd--