[9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

[Artem Smotrakov]

Here is an updated webrev which includes a fix for 8161086 (thanks 
Xuelei for help):
- No updates to the problem list
- CustomDatagramSocketImplFactory drops 5% of packets by default
- Updated DTLSInputRecord and DTLSOutputRecord to print sequence numbers 
if -Djavax.net.debug=ssl option is specified
- Updated InvalidRecords.java tests not to drop packets by default 
because handshaking unexpectedly succeeds if an invalid packet was dropped

http://cr.openjdk.java.net/~asmotrak/8159416/webrev.03/

Please take a look.

Artem

On 07/28/2016 04:36 PM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> I updated CustomDatagramSocketImpl class to be able to drop some 
> packets randomly or by specified numbers.
>
> While updating the test, I found 
> https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the 
> root cause of these intermittent failures.
>
> I added a couple of PacketLoss* tests to reproduce and verify 8161086. 
> These tests drop different packets while handshaking. They use 
> different cipher suites and modes, so that they take a while. I didn't 
> notice they fail with timeout, but I suspect that may happen on slower 
> machines. That's why I increased timeout value for them. I added the 
> tests to the problem list since 8161086 is not fixed yet.
>
> There are a couple of other updates to DTLSOverDatagram.java:
> - Server tries to receive first application data when it finishes 
> handshaking. Server re-sends final handshaking messages if timeout 
> reached while waiting for application data from client.
> - Updated client and server to use simple threads instead of thread 
> pools. This way, it's possible to specify meaningful names for threads 
> which makes logs more readable if "-Djavax.net.debug=ssl" specified
> - Added more logging
> - Made some fields final
>
> At the moment, CustomDatagramSocketImplFactory doesn't drop packets by 
> default because it may cause intermittent failures of tests which are 
> based on DTLSOverDatagram class:
>
> ...
>     static class CustomDatagramSocketImplFactory
>                 implements DatagramSocketImplFactory {
> ...
>     // if true, it's going to drop some packets
>     private static boolean dropPackets = false;
> ...
>
> When 8161086 is fixed, it may be set to true by default. Currently the 
> packet loss rate is 5% which I think is much more than if we use UDP 
> sockets on localhost, so that we test DTLS impl in worse conditions.
>
> Could you please take a look at updated webrev?
>
> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/
>
> Artem
>
> On 06/27/2016 06:25 PM, Xuelei Fan wrote:
>> On 6/28/2016 9:12 AM, Artem Smotrakov wrote:
>>> Hello,
>>>
>>> Please review this patch for javax/net/ssl/DTLS tests.
>>>
>>> A couple of DTLS tests fail intermittently on Mac with timeout or "Too
>>> many handshake loops ..." error. The tests use UDP to transfer DTLS
>>> records. It happens sometimes that server cannot receive UDP packets
>>> with DatagramSocket.receive() method even if client tries to re-send
>>> them multiple times. Please see logs in the bug.
>>>
>>> At the moment, it is not clear why UDP packets can't be delivered to
>>> server. If someone has seen something similar before, or has some ideas
>>> what might be the root cause, please let me know.
>>>
>> UDP is not reliable.  It could happen that the packets get lost.
>>
>>> I think that the tests and DTLS implementation are fine here. Since the
>>> tests are for DTLS, we can workaround this issue by avoiding real UDP
>>> connections. To avoid changing test logic much, we can use a custom
>>> DatagramSocketImpl and DatagramSocketImplFactory implementations to
>>> replace system UDP implementation.
>>>
>>> The patch below updates the tests with the following:
>>> - added custom DatagramSocketImpl and DatagramSocketImplFactory
>>> implementations to avoid real UDP connections
>> Tests for real connections in practice are needed.  If we update this
>> test this way, we need to add other tests to test real application
>> usage.  I don't think this is the right direction to avoid real UDP
>> connections.
>>
>>> - added more test output, so that we can have more info it the tests
>>> fail again
>>>
>> I agree with this point.
>>
>> Xuelei
>>
>>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac,
>>> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on
>>> all supported generic platforms, and they worked fine.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416
>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/
>>>
>>> Artem
>