Re: [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.ji...@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.ji...@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