tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [5] Proposal: webapp startup
Date Tue, 20 Aug 2002 20:59:53 GMT
Aha !

I think I got it, it has nothing to do with the naming... When I do a 
start() and try to do the config in the background, the 'ok' return 
status is not set and the main thread believe an error happened and
resets the resource field.



Costin


On Tue, 20 Aug 2002 costinm@covalent.net wrote:

> On Tue, 20 Aug 2002, Alex Chaffee / Purple Technology wrote:
> 
> > 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.
> 
> Probably that's the best - and should be the only 'option'.
> 
> 
> > 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.
> 
> +1
>  
> > If I wanted to make a patch proposal, what source file(s) should I
> > look at?  It's been a while...
> 
> I'm not sure - I'm still confused by the dozens of interfaces/base 
> classes/etc. Hopefully coyote and the jndi config will simplify that.
> 
> The critical issue is making the context init work in another thread - I 
> tried putting the webapp initialization in a separate thread but
> can't figure the context binding. And I tried a lot of tricks... If 
> Remy can do that...
> 
> What I did is make ContextConfig implement Runnable, rename start() 
> to run() and added a start() method with:
>     new Thread(this).start();
> 
> However I can't get it to find web.xml and anything else. I tried
> bindThread - but doesn't seem to work.
> 
> 
> > 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 :-)
> 
> That's a matter of taste. I would rather see a page saying 'the
> app is starting, it'll be ready in few minutes' - or a smart 
> guy could tune this and add some intermediary screen, maybe some
> javascript progress bar. Waiting 30 seconds is not a good impression.
> 
> And the current alternative is not beeing able to connect to the 
> site ( since the server is down ). Much worse...
> 
> The 503 can also be used by lb to go to a different instance.
> 
> 
>  
> > * 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).  
> 
> I agree with this one. Probably configurable is the best choice, and 
> until that the 'wait' behavior is better.
> 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
> 
> 


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