Am 07.04.2017 um 11:22 schrieb Rémy Maucherat:
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.

Hi Rémy

what about:

Index: build.xml
===================================================================
--- build.xml   (revision 1790439)
+++ build.xml   (working copy)
@@ -1480,6 +1480,8 @@
<exclude name="org/apache/tomcat/util/net/jsse/openssl/**" unless="${test.openssl.exists}" /> <!-- Exclude performance tests. E.g. on systems with slow/inconsistent timing --> <exclude name="**/*Performance.java" if="${test.excludePerformance}" />
+            <!-- Exclude a configurable list of tests -->
+            <exclude name="${test.exclude}" />
           </fileset>
         </batchtest>
       </junit>


so one can exclude tests by listing them in property "test.exclude". For me on Solaris TestSsl hangs the test suite, so I would prefer to skip/exclude it, all others currently do not have a problem with it. So we can keep the test enabled for now and I will disable it in my environment using the new test.exclude property. Once more people or Gump etc. report failures we can officially skip it.

WDYT?

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to