tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Majors, Jeremy" <>
Subject Re: Expected Delay when Switching to New Version of Application Using Parallel Deployment (Tomcat 7.0.27)
Date Fri, 12 Jul 2013 14:08:09 GMT
Thanks Chris for the suggestions.  At this point I think it will be good
enough for our needs.  Your comments have helped me understand the
process/inner-workings better.


On 7/11/13 10:39 AM, "Christopher Schultz" <>

>Hash: SHA256
>On 7/9/13 9:58 AM, Majors, Jeremy wrote:
>> On 7/8/13 10:52 PM, "Christopher Schultz"
>> <> wrote:
>> Jeremy,
>> On 7/5/13 11:24 AM, Majors, Jeremy wrote:
>>>>> For a simple web application, what is the expected delay
>>>>> when switching to new version of an application when using
>>>>> the parallel deployment process?  I'm trying to do timings
>>>>> right now with a single Hello World JSP and sometimes there
>>>>> is a delay of up to 4 seconds when the new version of the
>>>>> application is deployed (running 5 users simultaneously using
>>>>> Jmeter with cookies turned off), but other times I don't see
>>>>> this behavior.
>> How are you deploying the new version? Are you dropping another
>> WAR file into the webapps/ directory, or are you using the manager
>> webapp to deploy the new version?
>>> Our current deployment mechanism involves placing a new
>>> context.xml file in {tomcat.root}/conf/Catalina/localhost/ which
>>> has the docbase property set to an already exploded WAR.
>I suspect you are seeing the delay caused by Tomcat only
>periodically-polling for deployment descriptor updates: they are not
>instantaneous. I think you can adjust the polling time by setting the
>backgroundProcessorDelay attribute on your <Host> element. (I looked
>at the code to determine if this was true, but I can't seem to prove
>it. I don't see any other options that could affect this polling-time,
>so I suspect this is the case).
>Note that reducing the backgroundProcessorDelay from the default of 10
>may lead to performance problems, as a lot of resources are scanned to
>see if any of them has changed.
>If you want to allow for near-instantaneous redeployment, you should
>use the manager webapp directly, and possibly set autoDeploy=false.
>- -chris
>Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>Comment: GPGTools -
>Comment: Using GnuPG with Thunderbird -
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message