On Thu, Dec 8, 2016 at 4:20 AM Mark Thomas <ma...@apache.org> wrote: > On 07/12/2016 15:21, Christopher Schultz wrote: > > John, > > > > On 12/7/16 7:19 AM, John D. Ament wrote: > >> On Wed, Dec 7, 2016 at 3:58 AM Mark Thomas <ma...@apache.org> > >> wrote: > > > >>> On 06/12/2016 02:59, John D. Ament wrote: > >>> > >>> <snip/> > >>> > >>>> So I was able to identify my issue. It's not specifically a > >>>> tomcat problem, but tomcat's bootstrapping makes it unique. > >>>> > >>>> one of the issues I've observed is that Tomcat's use of > >>>> multithreading causes some thread deadlocking with some > >>>> synchronized blocks. I was wondering if there's a way to turn > >>>> that off? Make tomcat's bootstrap happen in the same thread as > >>>> the original invocation? > >>> > >>> What exactly do you mean by Tomcat's bootstrapping? Can you give > >>> an example of concurrent execution that is causing issues? > >>> > > > >> I instantiate the Tomcat object and invoke start() on the "main" > >> thread. The invocation of ServletContextListeners happens on a > >> "localhost-startStop-1" thread. I would like to have that > >> invocation happen on the main thread instead. > > > > Hmm... there is the "startStopThreads" setting on the Engine, but > > unfortunately there is not (currently available) setting that says > > "don't use multiple threads at all". It looks like Tomcat is always > > going to use at least one (separate) thread to launch the various > > Hosts (and webapps). > > It wouldn't be too hard to change that to not use an executor if the > default of startStopThreads="1" was being used. However... > > >> Its nothing within tomcat that is deadlocking, but under the covers > >> weld has a synchronized block, its inside that synchronized block > >> where Tomcat is instantiated. There's a later point where Weld > >> tries getting a lock again. In that case, when its single threaded > >> (in other containers) it passes since it has a lock, but in this > >> case it can't get that lock. > > The Weld documentation suggests that it is initialized per web > application with a ServletContainerInitializer. This would be fine with > Tomcat's current use of an Executor for container start/stop. > > I don't, therefore, understand how Weld is instantiating Tomcat. Can you > expand on this? > > There's two ways to make this work. The documentation you're reading is referring to standard servlet containers. E.g. someone's installed tomcat somewhere and has a WAR with weld-servlet in it.
In my case, I'm using weld-se to bootstrap a JVM, wrote a CDI extension that bootstraps Tomcat embedded, pointing to the embedded weld instance. Its not designed for multiple apps, but a single service in that JVM. Since I'm using an extension, weld isn't 100% started yet. Since it hasn't started yet, some of the bootstrap logic is trying to fire an event. That event shouldn't be fired quite yet, and its not able to coordinate that between the threads, hence where I got this problem. I ended up working around the issue by delaying Tomcat's bootstrap even further, ensuring that the container is 100% up before trying to launch tomcat. > Mark > > > Is there any way for you to remove the required monitor on your own > > code? Or is Weld so intricately-involved in the whole process that > > unwinding it isn't possible? > > > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
