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 can
cause the attempted send from server socket to client not to occur.
 
the sock.send() can result in the application data being copied into the
kernel 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 etc
           DatagramSocket 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 place
           DatagramSocket 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

 

Reply via email to