2017-04-06 21:57 GMT+02:00 Rainer Jung <rainer.j...@kippdata.de>:
> I am not much close, but r1781988 broke it:
>
> "Ensure that executor thread pools used with connectors pre-start the
> configured minimum number of idle threads."
>
> The change itself is OK, but as a consequence the test is now executing
> with more threads in the executor:
>
> Index: java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
> ===================================================================
> --- java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java (revision
> 1781987)
> +++ java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java (revision
> 1781988)
> @@ -63,19 +63,23 @@
>
> public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
> keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue,
> RejectedExecutionHandler handler) {
> super(corePoolSize, maximumPoolSize, keepAliveTime, unit,
> workQueue, handler);
> + prestartAllCoreThreads();
> }
>
> public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
> keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue,
> ThreadFactory threadFactory,
> RejectedExecutionHandler handler) {
> super(corePoolSize, maximumPoolSize, keepAliveTime, unit,
> workQueue, threadFactory, handler);
> + prestartAllCoreThreads();
> }
>
> public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
> keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue,
> ThreadFactory threadFactory) {
> super(corePoolSize, maximumPoolSize, keepAliveTime, unit,
> workQueue, threadFactory, new RejectHandler());
> + prestartAllCoreThreads();
> }
>
> public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
> keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
> super(corePoolSize, maximumPoolSize, keepAliveTime, unit,
> workQueue, new RejectHandler());
> + prestartAllCoreThreads();
> }
>
> public long getThreadRenewalDelay() {
>
>
> So at least that's why I observed it first in 8.0.42, the version that
> change was included.
>
> But I'm not close to the root cause.
>
> Reproducability on my slow Solaris 10 Sparc system is very good, about 80%
> of all attempts show the hang.
>
> This test is skipped with NIO. With NIO2, it works for me, so it's not,
but when I had a look then, I became convinced it's impossible to guarantee
the process will work with async IO and the SSL engine. Basically, it's
really a blocking IO thing, preferably all integrated like with java.io.
However, the feature should be kept since usually the user will not be in
the worst case scenario, unlike the test.
So if this bothers you, the easiest at this point is to skip the test for
NIO2 in Tomcat 8.0.
Rémy
