[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #18 from Mark Thomas --- Thanks for the offer. I spend a little time looking at this over the weekend and I should have something ready to commit shortly. -- You are receiving this mail because: You are the

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #17 from John D. Ament --- I'm fine with that as well. Do you need me to make any changes to the patch? -- You are receiving this mail because: You are the assignee for the bug.

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #16 from romain.manni-bucau --- acceptable for me, thanks Mark -- You are receiving this mail because: You are the assignee for the bug. -

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #15 from Mark Thomas --- Given the concerns for existing applications - although I not convinced those concerns are entirely valid - I propose that this change is implemented for 9.0.x only and an appropriate

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #14 from Mark Thomas --- Why isn't the log4j2 issue just as much as a problem for an Executor thread that is used to start multiple web applications? I remain unconvinced that switching to the main thread when

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #13 from romain.manni-bucau --- side note: to speak about well known frameworks affected by that, log4j2 can lead to the mentionned issue when added to the container since it sets a threadlocal in initialzer

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #12 from romain.manni-bucau --- Ok, if you have a listener observing before_init or before_start on Context (or even org.apache.catalina.core.StandardHost#addChild) you can initialize some context there, if

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #11 from Mark Thomas --- You are going to have to explain that code sample. It means nothing to me. 0 and negative numbers are already defined to have special meaning. -- You are receiving this mail because:

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #10 from romain.manni-bucau --- > Code that relies on the deployment mechanism for correct clean-up is broken > and needs to be fixed. Deployment threads may be re-used before they are > stopped and if any

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #9 from Mark Thomas --- Code that relies on the deployment mechanism for correct clean-up is broken and needs to be fixed. Deployment threads may be re-used before they are stopped and if any component fails to

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #8 from romain.manni-bucau --- Fact is tomcat kind of guarantee you execute code in a specific thread pool (far from any user pool or http pool to be concrete). So there is now a lot of code relying on

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #7 from Mark Thomas --- (In reply to romain.manni-bucau from comment #4) > Can 1 keep current behavior and 0 or negative values use an executor > executing directly the task? 1 is used and relying on deployer

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #6 from John D. Ament --- Just to clarify: - If you don't specify the setting, or have it set to 0, you get the old behavior. - If you set it to 1, you get the new behavior. - If you set it to anything

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #5 from John D. Ament --- Romain, what would be the benefit of current behavior when threads == 1? This is specific to helping fix a problem w/ Weld and Tomcat integration where a deadlock can occur because

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #4 from romain.manni-bucau --- Can 1 keep current behavior and 0 or negative values use an executor executing directly the task? 1 is used and relying on deployer threads avoids to leak data where this change

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #3 from John D. Ament --- I also created a PR not sure which would be easier. https://github.com/apache/tomcat85/pull/6 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #2 from John D. Ament --- Created attachment 34660 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34660=edit Proposed code changes (based on dev discussion) -- You are receiving this mail because:

[Bug 60623] When startStopThreads is 1, don't rely on an executor and instead start synchronously

https://bz.apache.org/bugzilla/show_bug.cgi?id=60623 --- Comment #1 from Michael Osipov <1983-01...@gmx.net> --- Alternatively, one can provide a #join() method just like Jetty does in Server.class. -- You are receiving this mail because: You are the assignee for the bug.