On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard <mshep...@openjdk.org> wrote:
> The test java/net/Socket/UdpSocket.java has been seen to fail with a
> BindException, in the testMaxSockets test, on a regular basis on
> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
> Sockets that may be created as defined by a system property
> sun.net.maxDatagramSockets. It invokes the Socket constructor
> Socket(InetAddress host, int port, boolean stream) with stream set to false
> to create a UDP Socket. This instantiation is a compound operation,
> consisting of the creation of a socket, the explicit binding of wildcard
> address and ephemeral port, and a connect to the socket end point specified
> in the constructor parameters. Analysis has shown that during the test that
> the OS intermittently allocates the same ephemeral port multiple times during
> the bind system call, such that two separate sockets end up bound to the same
> port. Then on the connect invocation a BindException is thrown for the second
> socket. This has been determined to be a transient condition duri
ng heavy loads and where a significant number of ephemeral ports are being
allocated.
>
> As this is deemed an OS issues, and in order to increase test stability, it
> has been found that for the BindException condition a retry of the Socket
> creation mitigates the issues and tests the max creation property.
test/jdk/java/net/Socket/UdpSocket.java line 151:
> 149: }
> 150: }
> 151: return newUdpSocket;
I added this test in advance of JEP 353 as we didn't have much coverage for
this deprecated constructor. No objection to the retry if it helps. Is the
catching of SocketException a left over from testing? I assume the patch can be
simplified down to:
try {
return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
} catch (BindException e) {
System.out.println(...);
return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
}
-------------
PR: https://git.openjdk.java.net/jdk/pull/4103
