Created attachment 31514 [details] test log While this is the only error I see in whole Tomcat test suite it might be real issue. Please see attached report. java version "1.7.0_51"
JDK version = ?
jdk1.7.0
(In reply to Petr Sumbera from comment #2) > jdk1.7.0 The exact version please (e.g., 1.7.0_25).
$ /usr/jdk/instances/jdk1.7.0/bin/java -version java version "1.7.0_51" Java(TM) SE Runtime Environment (build 1.7.0_51-b34) Java HotSpot(TM) Server VM (build 24.51-b04, mixed mode)
Is this repeatable? It is possible that the test behaves differently on Solaris and we simply don't handle it.
Not here. Just ran that test 10 times for Tomcat 8 trunk with NIO, BIO and APR each on Solaris 10 Sparc using Java 1.7.0_51. No failures. Petr: Can you reproduce?
I could randomly reproduce it (on Linux), same stack trace. But it is odd, it does not happen with NIO2 for me, and I don't see why it wouldn't (the SSL code is the same use of SSL engine). I can't reproduce it if I run as a single test, but I can (one out of four times, I'd say) if running the full TestSsl series. Minor issue IMO since this doesn't happen much and this renegotiation test is just protocol abuse anyway.
I can't reproduce this on Windows or OSX (tried 10+ runs) either.
I've re-written the unit test. It still passes on Windows but now fails much more frequently on Windows. Getting to the bottom of why it fails is the next task.
With trunk at r1589300 the test now fails for me consistently in 10 of 10 runs on Windows 7 + JDK 7u55 32-bit. I am running with execute.validate=false execute.test.bio=false execute.test.nio=true execute.test.apr=false execute.test.nio2=false test.accesslog=false test.entry=org.apache.tomcat.util.net.TestSsl test.entry.methods=testSimpleSsl,testKeyPass,testRenegotiateWorks,testRenegotiateFail The last property is to fix order of the methods. All 10 failures are with the same "72" vs "-1" failure: [[[ Testcase: testSimpleSsl took 4,581 sec Testcase: testKeyPass took 0,926 sec Testcase: testRenegotiateWorks took 3,418 sec FAILED expected:<72> but was:<-1> junit.framework.AssertionFailedError: expected:<72> but was:<-1> at org.apache.tomcat.util.net.TestSsl.doRequest(TestSsl.java:158) at org.apache.tomcat.util.net.TestSsl.testRenegotiateWorks(TestSsl.java:135) ]]] Apparently there is no more "testRenegotiateFail" test, so only 3 tests methods were run.
On Linux it fails 100% of the time too now (it used to be about 50%). NIO2 still does not fail for whatever reason. I can investigate tomorrow if needed. My trace is on Linux is: Testcase: testRenegotiateWorks took 3.216 sec FAILED Failed on request number 1 after startHandshake() junit.framework.AssertionFailedError: Failed on request number 1 after startHandshake() at org.apache.tomcat.util.net.TestSsl.testRenegotiateWorks(TestSsl.java:138) Yes, testRenegotiateFail is gone, it is not needed as trunk requires Java 7, according to the commit. BTW http://ci.apache.org/builders/tomcat-trunk is up again, but not running anything.
Created attachment 31550 [details] test log (r1589303, Win7) Test log on Windows with trunk at r1589303. Failed on request number 2 after startHandshake(). expected:<72> but was:<-1>
I have been able to make a little progress debugging this. I still have not been able to reproduce this on Windows. 1. The issue appears to be timing related. On OSX I see the error when running from the command line but not when running through Eclipse. 2. It looks like the read() and write() methods in SecureNioChannel make assumptions about the return value of tasks() that are not correct if the client has triggered renegotiation.
From my debugging, in the test it is never NEED_TASK, so tasks() is not called (and it doesn't feel wrong). However, (tracing the write, since that is what the test is doing) the handshake status goes into NEED_WRAP and NEED_UNWRAP, which means the write should read. Not a good concept IMO ... More specifically about NIO2, this could be very difficult if not impossible to do it "right" (depending on what ends up being needed), since mixing read and write operations after the initial handshake would corrupt data or run into pending checks. This could be a candidate to end up as a known issue.
I have disabled this test for NIO (it was already disabled for APR) as the improved unit test has demonstrated that the current implementation is not reliable. I have created bug 56448 to track implementing improved renegotiation support.