tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: parallel webapp initializa‚Äčtion
Date Mon, 10 Oct 2011 18:16:18 GMT
On 10.10.2011 19:35, Felix Schumacher wrote:
> Am Montag, den 10.10.2011, 11:30 +0200 schrieb sasc sasc:
>> +1 for this enhancement. With configurable number of threads (default:
>> Runtime.getRuntime().availableProcessors())
>> I would also like to expand/add to this request: Making contexts available
>> for request processing continuously as they are started. This in combination
>> with parallel startup, would significantly improve startup time and
>> perceived availability in many situations.
>> If you have 9 applications which each takes 1 sec to start, and 1 app that
>> takes 5 minutes to start, even with parallel start up, you would still have
>> to wait at least 5 minutes before any of the applications are available for
>> request processing. If they could be made available continuously, then the 9
>> fast apps could start processing requests, even if the 5 min app is still
>> initializing.
> I believe you will get more problems, than you solve by serving requests
> too early. You might happen to serve a request to a context, which is
> not initialized, or to a context, which would not be responsible.

I think the goal is interesting, but not with a trivial implementation.
So e.g. it would not be OK to serve the root context instead of /myapp
only because the root context is already deployed and deploymentof
/myapp hasn't started yet.

It would be more of a preprocessing (build the list of contexts to
deploy), then concurrent startup ann making individual contexts
immediately available for the request that really belong to them.

Care would be needed for the parallel deployment in order to not
temporarily serve old versions because the latest version isn't yet
fully started.

Also it would be nice to be able to express dependencies. This might be
even a good feature for the simple case of first starting everything and
then making it available. Because if we use an executor then a simple
strategy like "start in alphabetical order" might no longer work.

> I think the proper solution to your problem would be to do
> initialization of your webapp in a background thread and put a flag into
> your application scope, when initialization is done. Combine that with a
> filter, which redirects every incoming request to a waiting page, if the
> flag is missing from your application scope.



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

View raw message