tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: svn commit: r1173082 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11NioProtocol.java test/org/apache/catalina/comet/TestCometProcessor.java
Date Wed, 21 Sep 2011 10:44:55 GMT
On 21/09/2011 01:41, Konstantin Kolinko wrote:
> 2011/9/20 Mark Thomas <markt@apache.org>:
>> On 20/09/2011 13:41, Konstantin Kolinko wrote:
>>>
>>> BTW: I am unable to reproduce Gump failure for TestCometProcessor with NIO
>>> (running with JDK 6u26/WinXP),
>>> but this test fails for me when running it with APR connector.
>>
>> I *think* I have all these issues fixed now. The unit tests pass for me
>> on Linux and Windows. We'll find out tomorrow if Gump is happy now. If
>> you could test APR as well that would be great.

Thanks for the test results.

> Running trunk @r1173433,
> BIO - OK (it actually skips the test)
> APR - OK
> NIO failed first 2 of 8 runs:
> 
> [[[
> ------------- ---------------- ---------------
> 
> Testcase: testSimpleCometClient took 17,813 sec
> 	FAILED
> expected:<Client: READ: [4] bytes> but was:<Client: READ: [8] bytes>
> junit.framework.AssertionFailedError: expected:<Client: READ: [4]
> bytes> but was:<Client: READ: [8] bytes>
> 	at org.apache.catalina.comet.TestCometProcessor.testSimpleCometClient(TestCometProcessor.java:97)
> 
> Testcase: testCometConnectorStop took 5,328 sec
> ]]]
> 
> IIRC it is expected (two subsequent network packets arriving to Tomcat
> without a delay between them)

That is unusual but not unexpected. We could handle that to prevent
false positives if you find it happening a lot.

> Also the following messages (they existed before),
>     [junit] 21.09.2011 4:18:14
> org.apache.catalina.util.SessionIdGenerator createSecureRandom
>     [junit] INFO: Creation of SecureRandom instance for session ID
> generation using [SHA1PRNG] took [5,016] milliseconds.

I think that is a side effect of starting lots of Tomcat instances one
after the other and using up the available entropy.

> (...)
>     [junit] 21.09.2011 4:18:22
> org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
>     [junit] SEVERE: The web application [] appears to have started a
> thread named [SeedGenerator Thread] but has failed to stop it. This is
> very likely to create a memory leak.

That looks like something triggered by the use of SecureRandom and may
be a genuine memory leak.

> and for APR connector (but it does not make it to fail):
> 
>     [junit] 21.09.2011 4:18:22 org.apache.tomcat.util.net.AprEndpoint
> allocatePoller
>     [junit] INFO: Failed to create poller with specified size of 8192

That is expected with Windows that can't handle the default poller size.

Mark

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


Mime
View raw message