You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@covalent.net on 2002/08/20 18:59:11 UTC
[5] Proposal: webapp startup
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.
There are several options for how to load:
1. load-on-startup, serial ( maybe with ordering). That's the current
situation. All webapps declared in server.xml are loaded in the defined
order - and if we move to separate .xmls for each webapp in webapps,
we can add an 'sequence' option and require it to be loaded sequencialy
and before the server port is started.
2. load-on-startup, parallel. That's very usefull if we have many
applications and will speed up the startup. The server port will
begin accepting connections after all apps with load-on-startup are
loaded.
3. load-on-startup, delayed. For some applications it may be usefull
to not delay the start of the server - the startup will be done in
background and no request for it will be served until the app is ready.
4. load-on-demand. The context will be initialized when the first
request for that context is received. That is the only reasonable choice
if you have many ( 50+ ? ) small webapps ( say a hosting env ).
I don't see this as a big priority, but nice to have. I'll implement
the 'load-on-startup, parallel' as soon as I figure how to do the
thread binding and find the time.
For example, the admin/ app can be very well loaded on demand or
delayed - and same for any app that is not 'critical'.
It is far better to have tomcat restart quickly and have minimal
downtime for the frequently used apps ( where load-on-startup is
a good choice ), and use delayed for less-frequent or less critical apps.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH][Catalina] Validation turned off by default.
Posted by Jean-francois Arcand <je...@sun.com>.
Hi,
attached is a patch that implement the mechanism to turn off/on the XML
validation and namespace awareness. Starting with this patch,
validation/namespace will be turned off. If you want to turn it on, do:
<Host name="localhost" debug="0" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="true" xmlNamespaceAware="true">
*xmlValidation and xmlNamespaceAware are optional attributes. Current
server.xml file are still supported.
I did not implement the functionality for server.xml and user.xml since
the validation was turned off by default (and willnot work if validation
is turned on).
Thanks,
-- Jeanfrancois
Re: [5] Proposal: webapp startup
Posted by Remy Maucherat <re...@apache.org>.
Jean-francois Arcand wrote:
>
>
> costinm@covalent.net 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.
>>
>> There are several options for how to load:
>>
>> 1. load-on-startup, serial ( maybe with ordering). That's the current
>> situation. All webapps declared in server.xml are loaded in the defined
>> order - and if we move to separate .xmls for each webapp in webapps,
>> we can add an 'sequence' option and require it to be loaded sequencialy
>> and before the server port is started.
>>
>> 2. load-on-startup, parallel. That's very usefull if we have many
>> applications and will speed up the startup. The server port will
>> begin accepting connections after all apps with load-on-startup are
>> loaded.
>>
>> 3. load-on-startup, delayed. For some applications it may be usefull
>> to not delay the start of the server - the startup will be done in
>> background and no request for it will be served until the app is ready.
>>
>> 4. load-on-demand. The context will be initialized when the first
>> request for that context is received. That is the only reasonable
>> choice if you have many ( 50+ ? ) small webapps ( say a hosting env ).
>>
>> I don't see this as a big priority, but nice to have. I'll implement
>> the 'load-on-startup, parallel' as soon as I figure how to do the
>> thread binding and find the time.
>>
>> For example, the admin/ app can be very well loaded on demand or
>> delayed - and same for any app that is not 'critical'.
>
> Actually, implementing the xml validation on/off mechanism, admin/ is
> _the_ reason why Tomcat is slow at startup.
I know, at it is the only major difference between TC 4.0 and 4.1 in the
startup time. The new Beanutils 1.4.1 also fixes a performance bug which
could help things big time (and right on time before the 4.1 release).
> There is a lot of xml files
> to parse/validate in that application....so I'm +1 to load on demand and
> set validation to false :-)
Cool :)
I'm sooo tempted to try to port that for 4.1.10, but this is bad as it
greatly affects the behavior of Tomcat. Maybe it would be best to leave
it for a major release. Or it could be ported, by we'd have to default
to always validate.
> I know it may involve a lot of work, but It might be nice to have an
> option in server.xml that configure the "web-app startup" mode?
Implementing them all would be painful IMO ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Proposal: webapp startup
Posted by co...@covalent.net.
On Tue, 20 Aug 2002, Jean-francois Arcand wrote:
> Actually, implementing the xml validation on/off mechanism, admin/ is
> _the_ reason why Tomcat is slow at startup. There is a lot of xml files
> to parse/validate in that application....so I'm +1 to load on demand and
> set validation to false :-)
It's not _the_ reason, just one of the reasons.
Try taking off the jmx listeners - you'll see a difference.
I'll start commiting ( really soon :-) the common-logging changes,
and one thing I added in various places is logging the time
it takes to do various operations ( if it's > 200 ms ). I think
I get most of the 'suspects' accounted for.
I already mentioned that for me the 'minimal' tomcat5 starts in 6 seconds
- all the extra stuff can be put in background.
Costin
>
> I know it may involve a lot of work, but It might be nice to have an
> option in server.xml that configure the "web-app startup" mode?
>
> -- Jeanfrancois
>
> >
> >It is far better to have tomcat restart quickly and have minimal
> >downtime for the frequently used apps ( where load-on-startup is
> >a good choice ), and use delayed for less-frequent or less critical apps.
> >
> >
> >
> >Costin
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Proposal: webapp startup
Posted by Jean-francois Arcand <je...@sun.com>.
costinm@covalent.net 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.
>
>There are several options for how to load:
>
>1. load-on-startup, serial ( maybe with ordering). That's the current
>situation. All webapps declared in server.xml are loaded in the defined
>order - and if we move to separate .xmls for each webapp in webapps,
>we can add an 'sequence' option and require it to be loaded sequencialy
>and before the server port is started.
>
>2. load-on-startup, parallel. That's very usefull if we have many
>applications and will speed up the startup. The server port will
>begin accepting connections after all apps with load-on-startup are
>loaded.
>
>3. load-on-startup, delayed. For some applications it may be usefull
>to not delay the start of the server - the startup will be done in
>background and no request for it will be served until the app is ready.
>
>4. load-on-demand. The context will be initialized when the first
>request for that context is received. That is the only reasonable choice
>if you have many ( 50+ ? ) small webapps ( say a hosting env ).
>
>I don't see this as a big priority, but nice to have. I'll implement
>the 'load-on-startup, parallel' as soon as I figure how to do the
>thread binding and find the time.
>
>For example, the admin/ app can be very well loaded on demand or
>delayed - and same for any app that is not 'critical'.
>
Actually, implementing the xml validation on/off mechanism, admin/ is
_the_ reason why Tomcat is slow at startup. There is a lot of xml files
to parse/validate in that application....so I'm +1 to load on demand and
set validation to false :-)
I know it may involve a lot of work, but It might be nice to have an
option in server.xml that configure the "web-app startup" mode?
-- Jeanfrancois
>
>It is far better to have tomcat restart quickly and have minimal
>downtime for the frequently used apps ( where load-on-startup is
>a good choice ), and use delayed for less-frequent or less critical apps.
>
>
>
>Costin
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Proposal: webapp startup
Posted by co...@covalent.net.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Proposal: webapp startup
Posted by co...@covalent.net.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] Proposal: webapp startup
Posted by Alex Chaffee / Purple Technology <gu...@stinky.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>