Hi Daniel, a couple of observations and few points to consider in the UnreferencedMulticastSockets test.
similar to the DatagramSocket version but for this one MulticastSocket will automatically set the so_reuseaddr option. This has implications when the second MulticastSocket is created. Unlike the DatagramSocket socket version this test will use the same client address for both MulticastSocket created. Thus there is a stronger dependency between the try with resourses statement and the code that creates the second MulticastSocket for the send and receive. So does the second MulticastSocket need to use the same client unicast address ? There doesn't seem to be any multicast semantics in the test, other than creating a MukticastSocket, which is_a DatagramSocket. Can it be assured that there is no asynchrony in the synthesized code for the autoclose in the try with resources, both at the java level and within the OS kernel executing the close? Would an explicit close of the first MulticastSocket add better determinacy to the test execution? It could happen in a heavily loaded system, that if the close is asynchronous (Windows ?) that when the server has echo back the datagram there are still two extant sockets in the OS kernel and which socket receives the packet is indeterminate - this is not a multicast send and receive but a unicast send and receive. This could lead to intermittent client receive requests hanging (?) Note also that the client socket "connect" to the server address, meaning that it sends and receive datagrams from that peer address only. In the DatagramSocket version, a level of synchronization between the server thread and the main thread was added, would that be appropriate here again? best regards Mark ________________________________ From: net-dev <net-dev-boun...@openjdk.java.net> on behalf of Daniel Fuchs <daniel.fu...@oracle.com> Sent: Thursday 26 September 2019 14:16 To: OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: (teststabilization) RFR: 8231506: Fix some instabilities in a few networking tests Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8231506 8231506: Fix some instabilities in a few networking tests webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8231506/webrev.00/ There's one remaining test that still uses the wildcard (SocketImplCombinations). It has been observed failing in the past, and hopefully this change will fix it. The UnreferencedMulticastSockets, which has also been observed failing is also be updated with some more diagnosis. Finally, the DigestEchoServer$TunnelingProxy class has also been observed causing some instabilities in the httpclient tests that use it: the proxy tunnel doesn't properly propagate errors from downstream to upstream, and conversely, which sometimes leaves the reader waiting for data that will never come. This change should fix that. best regards, -- daniel
