On 10/10/2011 19:16, Rainer Jung wrote: > 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.
Logically, starting to accept requests after ROOT is deployed is similar to auto-deploying apps any time after the server has started. Would it be hard to start ROOT first (as a special case) and then start the rest of the applications? This would also permit the previously suggested idea[1] of loading a simple default ROOT application, if none is supplied[2]. acceptRequestsAfterRootBoot="true" sounds nifty ;) p 1. but I can't remember why who. 2. I remember thinking that Servlet 3.0 would make it easy to supply a simple webapp, but can't remember the details
signature.asc
Description: OpenPGP digital signature
