tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee / Purple Technology <g...@stinky.com>
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, costinm@covalent.net wrote:
> There are several possible use cases, and I think we should try to
> provide options to support each one.

Agreed.

> 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
503.

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
configure.

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                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message