On Wed, 19 May 2021 05:56:07 GMT, Alan Bateman <al...@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 dur
 ing 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);
> }

yes, thanks for that  ... updated as requested

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

Reply via email to