Hi Daniel, thanks for the reply π regards Mark
________________________________ From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Monday 12 August 2019 10:44 To: mark sheppard <macanao...@hotmail.com>; OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: Re: [teststabilization] RFR 8229348: java/net/DatagramSocket/UnreferencedDatagramSockets.java fails intermittently Hi Mark, On 10/08/2019 21:14, mark sheppard wrote: > It is suggested that the use of wildcard address (INADDR_ANY) is a > contributing factor, but i'mβ > not sure that is a correct assumption. That certainly did fix the intermittent failure we had in the new httpclient tests - especially on solaris, back when we were heavily hammering them prior to integration. > Just to emphasize the reuse address option is not on the IP address but > rather on the IP address and port β > combination, or at least that what is was meant to be. In the TCP > context there are other restrictions, also.β yes. β > Your change is to the "server socket", but the client is a symmetric > equivalent, DatagramSocket onβ > wildcard and ephemeral port, so the echo send from the server could > equally be sent astray!!β > That is, if the wildcard addressing is an issue.β Oh - darn. Thanks for noticing this! I should change the client too. > Looking at the overall structure of the test, is it not possible, that > the server socket has beenβ > GCed, finalized and so closed, prior to the server's packet send having > been completed within the OS, and so theβ > client hangs. β I doubt this would happen with UDP since the message should already have been sent - but just in case I'm adding a countdown latch just to eliminate the possibility. Here is a new webrev: webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8229348/webrev.01/ best regards, -- daniel > 8229348: java/net/DatagramSocket/UnreferencedDatagramSockets.java > fails intermittently > https://bugs.openjdk.java.net/browse/JDK-8229348