<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-serif; font-size: 12pt;">
<span><span>Hi Daniel,<br>
</span>
<div> fwiw a couple of points in passing on your change,​</div>
<div>while noting the rationale for the change.​</div>
<div>​</div>
<div>It is suggested that the use of wildcard address (INADDR_ANY) is a contributing factor, but i'm​</div>
<div>not sure that is a correct assumption. The sockets created in the initial version of the test​</div>
<div>bind to inaddr_any and an ephemeral port. The ephemeral port is chosen by the OS. So for another​</div>
<div>test to have the same port as those in this test would suggest an issue in the OS port allocation​</div>
<div>strategy.​</div>
<div>This also applies to the recent tagging of test/jdk/java/net/DatagramSocket/ReuseAddressTest.java ​</div>
<div>as intermittent failure due to SO_REUSEADDR. All the DatgramSocket, in this test, are using INADDR_ANY and​</div>
<div>an ephemeral port. Other than the multicastsocket scenario, which also uses an ephemeral port and​</div>
<div>set the so_reuseaddr options, all datagramsockets use wildcard and an ephemeral, making an endpoint​</div>
<div>clash with another test unlikely.​</div>
<div>​</div>
<div>​</div>
<div>Just to emphasize the reuse address option is not on the IP address but rather on the IP address and port ​</div>
<div>combination, or at least that what is was meant to be. In the TCP context there are other restrictions, also.​</div>
<div>​</div>
<div>Your change is to the "server socket", but the client is a symmetric equivalent, DatagramSocket on​</div>
<div>wildcard and ephemeral port, so the echo send from the server could equally be sent astray!!​</div>
<div>That is, if the wildcard addressing is an issue.​</div>
<div>​</div>
<div>Looking at the overall structure of the test, is it not possible, that the server socket has been​</div>
<div>GCed, finalized and so closed, prior to the server's packet send having been completed within the OS, and so the​</div>
<div>client hangs. ​</div>
<div>​</div>
<div>So a little jackanory in the context of jtreg execution with many tests executing concurrently,​</div>
<div>it would seem possible, although may be wild conjecture, that client send packet to server, client executes receive and​</div>
<div>blocks on i/o. Server (thread) receives packet and then echoes the packet, this is copied from user space into the​</div>
<div>kernel space and placed on queue for send (send is pending), and OS send call returns,</div>
<div> server releases socket, which is available for GC. With the heavy load on the​</div>
<div>test system, with hundreds, maybe thousands of threads, the server echo packet is pending send,​</div>
<div>and client hasn't received the echo packet. In the meantime GC is scheduled​</div>
<div>and eager beaver it reclaims the released server socket. This closes the server socket, which in turn drops the pending​</div>
<div>echo datagram, and the client continues to wait in receive. ??​</div>
<div>So it could be down to the load on the system, the number of concurrently executing threads, and whether the</div>
<div>GC thread executed before the server's echo packet send was completed within the OS kernel.</div>
<div>​</div>
<div>​</div>
<div>sometimes with the intermittently failing test there is a quirkiness about the net config on the test system,​</div>
<div>it can be useful for diagnostic assistance to dump the config at the start of the test.​</div>
<div>​</div>
<div>in summary, the use of wildcard address (inaddr_any) and ephemeral port should not be an issue here in this context.​</div>
<div>There should be no conflicts for OS allocated ephemeral ports.​</div>
<div>making your change to the "server socket", should it be equally applied to the client datagram socket?​</div>
<div>​</div>
<div>regards​</div>
<span>Mark</span><br>
</span></div>
<div>
<div id="appendonsend"></div>
<div style="color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif; font-size:12pt">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font color="#000000" face="Calibri, sans-serif" style="font-size:11pt"><b>From:</b> net-dev <net-dev-bounces@openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs@oracle.com><br>
<b>Sent:</b> Friday 9 August 2019 15:36<br>
<b>To:</b> OpenJDK Network Dev list <net-dev@openjdk.java.net><br>
<b>Subject:</b> [teststabilization] RFR 8229348: java/net/DatagramSocket/UnreferencedDatagramSockets.java fails intermittently</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Hi,<br>
<br>
Please find below a trivial fix for:<br>
<br>
8229348: java/net/DatagramSocket/UnreferencedDatagramSockets.java<br>
fails intermittently<br>
<a href="https://bugs.openjdk.java.net/browse/JDK-8229348">https://bugs.openjdk.java.net/browse/JDK-8229348</a><br>
<br>
webrev: <a href="http://cr.openjdk.java.net/~dfuchs/webrev_8229348/webrev.00/">http://cr.openjdk.java.net/~dfuchs/webrev_8229348/webrev.00/</a><br>
<br>
This test has been observed failing intermittently in our CI.<br>
The test failed in timeout - and there's no message saying<br>
that the expected reply has been received or that any file<br>
descriptor has been freed.<br>
I suspect the test was blocked in receive() in its main() method<br>
due to port reuse issues.<br>
<br>
The usual fix for that is to avoid binding to the wildcard.<br>
<br>
best regards,<br>
<br>
-- daniel<br>
</div>
</span></font></div>
</div>
</body>
</html>