Hi Julia,
Your change looks OK but it will increase the worst case, running time of test from (2500+1000)ms to (15000 + 1000)ms and this will definitely decrease the probability of intermittent failure but not 100% full proof.
Thanks,
Vyom
----- Original message -----
From: Julia Boes <julia.b...@oracle.com>
Sent by: "net-dev" <net-dev-boun...@openjdk.java.net>
To: OpenJDK Network Dev list <net-dev@openjdk.java.net>
Cc:
Subject: [EXTERNAL] Re: RFR: 8232513: java/net/DatagramSocket/PortUnreachable.java still fails intermittently with BindException
Date: Fri, Dec 6, 2019 6:00 PM
Hi Mark,
The test has a potential problem, that is the socket close cancause the attempted send from server socket to client not to occur.the sock.send() can result in the application data being copied into thekernel and queued for sending. But the send may not take place immediately.The data may not yet be sent when immediate close()is executed causing the socket's buffers and data to be released without sending.lines 24 etcDatagramSocket sock = recreateServerSocket(serverPort);b = "Greetings from the server".getBytes();packet = new DatagramPacket(b, b.length, addr, clientPort);sock.send(packet);sock.close();placing a small delay before the close appears to allow the send to take placeDatagramSocket sock = recreateServerSocket(serverPort);b = "Greetings from the server".getBytes();packet = new DatagramPacket(b, b.length, addr, clientPort);sock.send(packet);Thread.sleep(1000);sock.close();Thanks for the insight. I wasn't able to observe the SocketTimeout on Windows but that sounds reasonable. I added a Thread.sleep(1000) before sock.close().
Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8232513/webrev.01/
Best,
Julia