[9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort()

[Weijun Wang]

OK, so neither Windows not Linux is reusing the port number immediately.

But I don't want to rely on this observation. The Windows behavior is 
especially suspicious because it is a simple increment. If the current 
free port for UDP is n and for TCP is m and n < m, then after we get the 
free UDP port n in the first round, we will have to loop from n to m 
until we find a free TCP port. The Linux behavior looks like choosing a 
random port. This is good but is it documented clearly? How about other 
platforms?

IMHO controlling the randomness inside the test looks more reliable to 
me. Also, the updated code still contains a loop and I don't think it's 
a big enhancement comparing to the existing loop.

The bug description is worried about "test stabilization issues". Have 
we seen intermittent failures on port already used in this case? If no, 
then I don't think it's necessary to make a change here.

Thanks
Max

On 7/11/2016 12:28, John Jiang wrote:
> Hi Max,
>
> On 2016/7/9 18:04, Wang Weijun wrote:
>> I am not sure. If in the first round a free port is chosen for UDP but it's not available for TCP, how can we avoid the same port being chosen again in the 2nd round? The DatagramSocket object is closed in the catch block and the port number is reclaimed by the OS. Will the OS reuse it immediately in the 2nd round?
> I tested the case with the below codes on Windows and Linux,
>
> for (int i = 0; i < 100; i++) {
>     try (ServerSocket ss = new ServerSocket(0)) {
>         int port = ss.getLocalPort();
>         System.out.println(port);
>         try (DatagramSocket us = new DatagramSocket(port,
>                 InetAddress.getByName("127.0.0.1"))) {
>         }
>     }
>
>     Thread.sleep(500);
> }
>
> The outputs like the followings:
> Windows 7:
>     57632
>     57633
>     57634
>     57635
>     57636
>     57637
>     57638
>     57639
>     57640
>     57641
>     57642
>     57643
>     57644
>     57645
>     57646
>     57647
>     57648
>     57649
>     57650
>     57651
>    ...
>
> Ubuntu 15.10:
>     45916
>     44807
>     33578
>     40244
>     46033
>     38966
>     34431
>     46026
>     40069
>     39013
>     39496
>     37745
>     36749
>     43594
>     45667
>     46410
>     36762
>     38565
>     35074
>     34843
>     ...
>
> With the results, the previous port is not reused by the subsequent
> round immediately.
>
> Best regards,
> John Jiang
>> --Max
>>
>>> On Jul 9, 2016, at 3:18 PM, John Jiang <sha.jiang at oracle.com> wrote:
>>>
>>> Hi Max,
>>>
>>> On 2016/7/8 16:19, Wang Weijun wrote:
>>>> The reason a loop is needed here is that both the TCT and UDP servers must listen on the same port number. With your fix, the TCP server finds a free port, but I doubt if it's free for the UDP server.
>>> Yes, it's possible that the port still be occupied by another DatagramSocket.
>>> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.01
>>>
>>> Best regards,
>>> John Jiang
>>>
>>>> --Max
>>>>
>>>>
>>>>> On Jul 8, 2016, at 2:35 PM, John Jiang <sha.jiang at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>> Would you like to review this patch for removing unnecessary usages on jdk.testlibrary.Utils.getFreePort() from security-libs tests?
>>>>> In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be modified for this issue.
>>>>> If I miss something, please let me know.
>>>>>
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160029
>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00
>>>>>
>>>>> Thanks!
>>>>>
>>>>> John Jiang
>>>>>
>>>>>
>