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.
We don't handle that case now, so I'm not sure it should be a pre-requisite for any implementation that starts Contexts in parallel. > 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. Again, we don't handle this case currently. > 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. That would make the configuration a lot messier than it is right now as well as going against the intention of the Servlet specification. >> 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
