tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee / Purple Technology <>
Subject Re: [5] Proposal: webapp startup
Date Tue, 20 Aug 2002 17:30:44 GMT

On Tue, Aug 20, 2002 at 09:59:11AM -0700, wrote:
> There are several possible use cases, and I think we should try to
> provide options to support each one.


> Regardless of the startup timing, in all cases no request will
> be served from an webapp until all initialization is done, including
> load on startup servlets. There are 2 options here:
>  1. Wait. The request will be delayed until the initialization completes.
>     The user will just see a slow request.
>  2. 503. A response page with 'application is temporarily unavilable' or
>   'starting' or 'refreshing' - eventually with a meta reload.

Options are good, but I vote for "wait" to be the default behavior.
(Supporting use cases are below.)

There is a third option, by the way:

3. Wait with timeout.  The request is queued, but if it takes longer
than a specified time to process (say, 20 seconds), then it returns a

The third case actually subsumes the first two, since case 1 is
enabled by setting the timeout very high, and case 2 is enabled by
setting it very low (like 0).  So I think this might be the best
design choice: only one algorithm to implement, only one setting to

If I wanted to make a patch proposal, what source file(s) should I
look at?  It's been a while...


Why I think Wait should be the default:

Use cases:

* Human UI: most naive users will tolerate a pause (of up to, say, 30
seconds) much better than they will understand that the proper
response to a 503 is to wait a moment and then click reload.  Instead,
they will think "this site is down" and go to your competitor's :-)

* Scripts: my test scripts launch Tomcat, then send a bunch of test
requests and verify the results.  A 503 will cause the tests to fail
(unless I write special code to handle that case).  

Behavior seems to be mixed now -- there's a window where requests will
fail, following which they will wait.  There's also a condition where
a request at just the wrong time will corrupt the webapp, causing all
future requests to fail, but since I haven't been able to reproduce it
I haven't reported it.

Alex Chaffee             
jGuru - Java News and FAQs
Creator of Gamelan       
Founder of Purple Technology
Curator of Stinky Art Collective

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

View raw message