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

[Chris Hegarty]

Looks good. Thanks.

-Chris

> On 21 Sep 2018, at 02:51, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> 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
>>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180921/c4a8e5f2/attachment-0001.html>