(teststabilization) RFR: 8231506: Fix some instabilities in a few networking tests

Daniel Fuchs daniel.fuchs at oracle.com
Mon Sep 30 16:47:47 UTC 2019


Hi Mark,

On 30/09/2019 13:37, Daniel Fuchs wrote:
> On 30/09/2019 12:56, mark sheppard wrote:
>> the first uses the InetSocketAddress allocated and then the second 
>> uses the same address, without bind  exception because of
>> the SO_REUSEADDR option being set,  even if the close had not 
>> completed at that time.
> 
> No. The second doesn't use the address. I agree that it might - if
> e.g. the system has run out of ephemeral ports, but I believe  it's
> highly unlikely.

I take it back. One of my test run exhibited this exact behavior:
The client's MulticastSocket was bound to the exact same address
than the server's MulticastSocket - and of course the test
failed (see below).

Then I played with that a bit by forcing the client to bind
to the same address than the server. On my machine, I could
observe that only the last bound socket received any traffic.
There seemed no way to make the server receive anything from
the client in that configuration.

So I revised the test logic: I added a Phaser to make sure
the client and server advanced in phase, and I also added
a loop to force the client to bind to a different address
(actually a different port) than the server if binding to
the ephemeral port returns the same port than the server.
(I could test that by forcing the first bind to use the
server port instead of port 0).

So here is now my new webrev:

http://cr.openjdk.java.net/~dfuchs/webrev_8231506/webrev.02/index.html

Only changes compared to webrev.01 are in UnreferencedMulticastSockets.

By any chance, do you remember why MulticastSocket sets SO_REUSEADDR ?

best regards,

-- daniel


=====================================================================

   DatagramServer addr: localhost/127.0.0.1: 48429
   serverMulticastSocket:: fd: java.io.FileDescriptor at 65dd3755, fd: 5, 
cleanup: java.net.SocketCleanable at 4ba89eb
socketImplClass: class java.net.PlainDatagramSocketImpl
socketImpl class name not matched: java.net.PlainDatagramSocketImpl != 
java.net.TwoStacksPlainDatagramSocketImpl
   client bound port: 48429
   clientMulticastSocket:: fd: java.io.FileDescriptor at 179da90c, fd: 9, 
cleanup: java.net.SocketCleanable at 725335c5
socketImplClass: class java.net.PlainDatagramSocketImpl
socketImpl class name not matched: java.net.PlainDatagramSocketImpl != 
java.net.TwoStacksPlainDatagramSocketImpl
ping sent to: localhost/127.0.0.1:48429
echo received from: /127.0.0.1:48429
----------System.err:(13/908)----------
java.lang.AssertionError: incorrect data received: expected: 2, actual: 1
	at UnreferencedMulticastSockets.main(UnreferencedMulticastSockets.java:151)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:830)




More information about the net-dev mailing list