On Wed, 14 Dec 2022 18:41:35 GMT, Matthew Donovan <[email protected]> wrote:
>> This fix is intended to address various time-out errors in tests that use
>> DTLSOverDatagram as a test template. Based on test output from those bugs
>> (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887,
>> JDK-8268899), this fix:
>>
>> * refactors the class to only create one additional thread
>> * adds a CountdownLatch so if the server thread doesn't start for some
>> reason, it is reported quickly
>> * cleans up code to remove a loop condition that never fired: tests always
>> time-out before too many loop iterations
>> * removes CipherSuite.java from ProblemList
>>
>> Ran the following tests 200 times each with no failures.
>> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
>> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
>> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
>> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
>> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java
>
> Matthew Donovan has updated the pull request incrementally with one
> additional commit since the last revision:
>
> formatting changes
Overall it looks good to me.
test/jdk/javax/net/ssl/DTLS/InvalidRecords.java line 42:
> 40:
> 41: /**
> 42: * Test that if handshake messages are crasged, the handshake would fail
crasged? Was that supposed to be "changed?"
test/jdk/javax/net/ssl/DTLS/InvalidRecords.java line 66:
> 64: if (needInvalidRecords.get() && (ba.length >= 60) &&
> 65: (ba[0x00] == (byte)0x16) && (ba[0x0D] == (byte)0x01) &&
> 66: (ba[0x3B] == (byte)0x00) && (ba[0x3C] > 0)) {
I just want to make sure - this test is only designed to be run for initial
handshakes with cookies, not resumed handshakes, correct? I assume that is the
intent since this test dates back to the initial DTLS release where resumptions
didn't use cookies (that was a recent change to include support for resumption
cookies).
-------------
Marked as reviewed by jnimeh (Reviewer).
PR: https://git.openjdk.org/jdk/pull/11558
