[12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

[Chris Yin]

Hi, Chris H

Thanks for your suggestion, changed as below to just print client bound port as you mentioned. Certainly, this is not a fix, just add some debug info, hope we could get next failure sample to prove the guess :)

New Changes:

diff -r c26fbf1434c4 test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
--- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 14:19:53 2018 -0700
+++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Fri Sep 21 09:45:40 2018 +0800
@@ -120,6 +120,7 @@
         thr.start();
 
         MulticastSocket client = new MulticastSocket(0);
+        System.out.printf("  client bound port: %d%n", client.getLocalPort());
         client.connect(svr.getHost(), svr.getPort());
         pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
         extractRefs(client, "clientMulticastSocket");

Regards,
Chris Y

> On 20 Sep 2018, at 7:11 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Thank you for looking at this issue Chris Y.
> 
> I don’t disagree with the changes, but if you want to confirm your
> suspicion, that the same port is being reused, then printing out
> the client’s bound port would do that ( since the servers port is
> already printed in the logs ). 
> 
> If such a change was integrated, then the next observed failure
> would confirm or disconfirm your suspicion.
> 
> -Chris H.
> 
>> On 20 Sep 2018, at 11:50, Chris Yin <xu.y.yin at oracle.com> wrote:
>> 
>> Loop net-dev since the test is under java/net, thanks
>> 
>>> On 20 Sep 2018, at 5:30 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Please review below minor change for 8199931, thanks
>>> 
>>> A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call “new MulticastSocket(0)” to create client socket that maybe in a little possibility it used same address with server, that will explain why the failure looks like client received data package from itself. Follow the guessing, I modified test code to explicit create client socket use same port with server, then got same failure error as reported bug on OEL7. Though I cannot make sure the guess is 100% match with the original failure, but at least we could try to prevent such possible scenario.
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8199931
>>> 
>>> changes:
>>> 
>>> diff -r 43668e3cae4d test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
>>> --- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 08:59:03 2018 +0200
>>> +++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 16:37:36 2018 +0800
>>> @@ -40,6 +40,7 @@
>>> import java.net.DatagramSocket;
>>> import java.net.DatagramSocketImpl;
>>> import java.net.InetAddress;
>>> +import java.net.InetSocketAddress;
>>> import java.net.MulticastSocket;
>>> import java.net.UnknownHostException;
>>> import java.nio.file.Files;
>>> @@ -119,7 +120,10 @@
>>>       Thread thr = new Thread(svr);
>>>       thr.start();
>>> 
>>> -        MulticastSocket client = new MulticastSocket(0);
>>> +        MulticastSocket client = new MulticastSocket(null);
>>> +        // prevent MulticastSocket reuse previous address, see 8199931
>>> +        client.setReuseAddress(false);
>>> +        client.bind(new InetSocketAddress(0));
>>>       client.connect(svr.getHost(), svr.getPort());
>>>       pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
>>>       extractRefs(client, "clientMulticastSocket”);
>>> 
>>> Regards,
>>> Chris
>> 
>