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

[John Jiang]

Hi Max,

On 2016/7/11 14:16, Weijun Wang wrote:
> 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.
OK. I won't change this test for this issue.
Thanks for your comments.

Best regards,
John Jiang
>
> 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
>>>>>>
>>>>>>
>>
>