tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Hang in TestSsl testRenegotiateWorks for NIO2 (was Re: [VOTE] Release Apache Tomcat 8.0.43)
Date Fri, 07 Apr 2017 12:49:27 GMT
Am 07.04.2017 um 11:22 schrieb Rémy Maucherat:
> 2017-04-06 21:57 GMT+02:00 Rainer Jung <rainer.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message