On 21/09/2011 01:41, Konstantin Kolinko wrote: > 2011/9/20 Mark Thomas <ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
