Revise TcpNioConnectionTests.testMultiAccept() and testNoMultiAccept()

[artembilan]

They fail on Java 17, at least for me on Windows:

java.net.ConnectException: Connection refused: connect

	at java.base/sun.nio.ch.Net.connect0(Native Method)
	at java.base/sun.nio.ch.Net.connect(Net.java:579)
	at java.base/sun.nio.ch.Net.connect(Net.java:568)
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588)
	at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
	at java.base/java.net.Socket.connect(Socket.java:633)
	at java.base/java.net.Socket.connect(Socket.java:583)
	at java.base/java.net.Socket.<init>(Socket.java:507)
	at java.base/java.net.Socket.<init>(Socket.java:287)
	at java.base/javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:271)
	at org.springframework.integration.ip.tcp.connection.TcpNioConnectionTests.testMulti(TcpNioConnectionTests.java:884)
	at org.springframework.integration.ip.tcp.connection.TcpNioConnectionTests.testMultiAccept(TcpNioConnectionTests.java:851)

[oxcafedead]

That's a very interesting bug, I have spent some time to understand the reason.
Still my understanding is quite superficial.

Seems like OpenJDK11 for Windows has some optimizations which lead to this issue.
For loopback addresses, they apply some shortened round trip time (1ms if I understand this correctly, or some minimum Windows default).

• Ticket: https://bugs.openjdk.org/browse/JDK-8250521
• Place with optimization: https://github.com/openjdk/jdk17/blame/74007890bb9a3fa3a65683a3f480e399f2b1a0b6/src/java.base/windows/native/libnio/ch/Net.c#L244
• Commit: http://cr.openjdk.java.net/~adityam/mat/8250521_jdk11/src/java.base/windows/native/libnet/net_util_md.c.udiff.html

My hypothesis: as we do create many connections one after another, somehow this slows our server down when it accepts new channels. It establishes the TCP connection, but our client thinks that no connections had been established.

As my knowledge in this area is weak, I don't have any low-level ideas of the cause of that server slowness. Maybe you guys know. The strange thing is that connections are established one by one, not concurrently - so maybe it is some cumulative effect.

P.S. I still can be fundamentally wrong about the cause :D
But, some evidence in favor of the hypothesis:

• Placing Thread.sleep in the loop before SocketFactory.getDefault().createSocket... fixes the test
• Changing "localhost" to a real DHCP address fixes the issue
• The test starts failing if it contains >=6 sockets locally for me

Also,

• Did not test on Linux, but I suppose it should work there.
• Did not test on earlier javas, but I suppose it should work for jdk<11

[artembilan]

Hi @oxcafedead !

Thank you for such a great investigation!

You know, I don't think it worth to try to understand why.
Perhaps a loopback algorithm in Java for Windows is with bugs yet.

This one really has fixed issue for me: InetAddress localHost = InetAddress.getLocalHost();

Feel free to open a Pull Request under your name!

Probably some other sporadically failing tests should be fixed similar way...
We can fix that on demand!