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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to