tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric P <eric.maill...@gmail.com>
Subject Re: "Application" vars -
Date Fri, 02 Jul 2010 02:29:51 GMT
> 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.


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


Mime
View raw message