On 15/12/2016 19:35, Christopher Schultz wrote: > John, > > On 12/14/16 10:01 PM, John D. Ament wrote: >> I was feeling ambitious so I gave this a shot. Here's what I >> changed: >> https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d3c > d1e750b48498ff2
That was pretty much what I was thinking. > My > > tack was going to be to create an ExecutorService that didn't > dispatch. That way, less code has to change. Seems like more work. And doesn't solve the original problem of the main thread holding a lock. > The problem with that approach is that, technically, the thread count > can change for a variety of reasons and it should behave correctly at > the time the contexts are started/stopped. > > I'd be interested in some comments on changing the behavior of Tomcat > based upon the documentation of startStopThreads. For a value of "1", > it explicitly says that 1 thread will be used. I'd be surprised if > Tomcat were not to use a single (separate) thread rather than the main > thread. > > Thing about this use-case: you have an embedded scenario where you > want to launch Tomcat and you expect the start() call to return fairly > soon so you can continue doing whatever you wanted to do. But instead > of using the "1 thread" to start all the contexts, it's using the > current thread and blocking you. That isn't what happens. The main thread always blocks until all the container start threads have completed. > I'm wondering if we need to invent a new magic number for this. > Unfortunately, 0 is already taken. Perhaps we could use a non-numeric > value for this special case. I don't see a need for that. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
