tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: "Application" vars -
Date Fri, 02 Jul 2010 08:27:45 GMT
Eric P wrote:
>> So it makes sense to go into what "disruption" means. I'm not 100% sure
>> about the following, it would be good if a tomcat heavyweight would
>> confirm/refute what I say.
>> When you initiate a webapp reload, Tomcat waits for requests that have
>> already started processing to terminate. This ensures that people who
>> accessed your app just before the webapp get a complete response. Once
>> that's done, the application is reloaded and your servlets' init 
>> methods are
>> called if necessary. During this time, incoming requests aren't 
>> denied, they
>> are just paused until the reload is complete.
>> So the only disruption people see is your application freezing up for the
>> time it takes to reload (which is going to depend on what you your
>> initialization consists of). No ugly server unavailable errors or 
>> anything
>> of the sort.
>> If you don't like the idea of your app freezing, think about this. 
>> Rereading
>> environment params without reloading has its own risks, namely potential
>> race conditions. Imagine you have 5 parameters, and requests are 
>> coming in
>> as you are reading these in and initializing your webapp. A request 
>> might be
>> handled while 2 params have been read, but 3 still contain the old 
>> values.
>> If you start to think about locking/synchronization to solve this you're
>> definitely better off just using Tomcat's reload mechanism.
>> So my answer would be, trust Tomcat's reloading process unless you
>> absolutely want to avoid your webapp freezing for the time it will 
>> take for
>> it to init (this depends on the webapp). If you want to do your own
>> "reloading", think long and hard about potential race conditions 
>> (which will
>> occur in all except the simplest cases).
>> Again, all this should probably be verified, you can set up very 
>> simple test
>> cases with a JSP that  sleeps, etc.
> Shay,
> I think you made a good case for keeping app vars in web.xml (i.e., 
> seems pretty apparent now that's where they belong).
> Thanks for taking the time to respond.  I sincerely appreciate it!
> Eric P.
Very neat explanation.

While not being a great specialist, I would just like to expone what may be an 
alternative, if one really wants to diminish the (apparent) time it takes for a new 
version of a webapp to become available.  Since I am no great specialist, I will just 
outline the idea without Java/servlet specifics.

(Maybe also I am barging through an open door, and there already exists a standard 
mechanism for doing this, but oh well..)

Imagine that you have 2 identical versions of the same intrinsic webapp deployed, like


You create a 3rd webapp webappX, which is the one the users see, and which is just a 
"dispatcher" to either one of the two webapps webappA and webappB.
So you now have :


The users always use the URL "/webappX".
When a call is made to webappX, /it/ decides, in function of some external parameter Y, 
whether to dispatch the call to either webappA or webappB.

Say that initially the external parameter Y (which could be a system-wide property) is set

so that all calls to "/webappX" are currently dispatched to /webappA.
Now you want to update webappA.
You change the parameter Y so that calls are now dispatched to (identical) /webappB.
Then you update (redeploy) webappA.  Users see no delay, because they get directed to webappB.
When webappA is deployed and started (which you could check by calling it directly),
you can reset the parameter Y to its former value, and users will again be dispatched to 
webappA.  Now you can redeploy webappB, to keep it in sync.

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

View raw message