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.hega...@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....@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....@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
>>
>
