<LE NOISE>
Hi Daniel,
interesting set of changes -
But could it be the case that, for some tests, you might change the operational
semantics of a test, when
this applying this change. For example, in the case of GetLocalAddress.
The original is to use a wild card for the server, and a directed address for
the
client connect. Thus the server is listening INADDR_ANY or the IPv6 equivalent,
accepts
a connection, then a check is made to see that socket created is bound to the
same address
as that specified in the clients connect request.
If the server socket is bound to a specific address then the socket created by
the accept
will (always) have the same address as that of initial server socket
(listener).
As the tests are run with 3 different java.net property settings, it is worth
asking if the tests behaves as expected
for the case when neither java.net property is set.
AFAIK, on windows it shows some ambiguity and difference to the default setting
described in
[1]. The default run returns IPV4 addresses, creates AF_INTET sockets and binds
to IPv4 addresses.
This is possibly at odds with the default property settings are described in
the docs.
java.net.preferIPv4Stack (default: false)
If IPv6 is available on the operating system the underlying native socket will
be, by default,
an IPv6 socket which lets applications connect to, and accept connections from,
both IPv4 and IPv6 hosts.
This implies that the first test run, i.e. default property settings, should be
an AF_INET6 socket as in new ServerSocket
should be bound to the IPv6 unspecified address.
While
java.net.preferIPv6Addresses (default: false)
When dealing with a host which has both IPv4 and IPv6 addresses,
and if IPv6 is available on the operating system, the default
behavior is to prefer using IPv4 addresses over IPv6 ones.
This implies that the InetAddress.getLocalHost() should in the default case
return an IPv4 address.
The client socket connect with IPv4 address to IPv6 wild card resulting in an
IPv4 mapped
binding in the socket created in the accept. This would mean the first run
should fail.
In any case a test using a server socket listening on a wildcard (INADDR_ANY)
address has possibly
slightly different semantics than a server socket listening on a specific host
address.
regards
Mark
</LE NOISE>
[1]
https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html
________________________________
From: net-dev <net-dev-boun...@openjdk.java.net> on behalf of Daniel Fuchs
<daniel.fu...@oracle.com>
Sent: Tuesday 30 April 2019 11:16
To: OpenJDK Network Dev list
Subject: RFR: 8223145: [teststabilization] Replace wildcard address with
loopback or local host in test - part 1
Hi,
Please find below a patch for:
8223145: [teststabilization] Replace wildcard address with loopback
or local host in test - part 1
https://bugs.openjdk.java.net/browse/JDK-8223145
http://cr.openjdk.java.net/~dfuchs/webrev_8223145/webrev.00/
This is the first in a series of patches that will try to
address intermittent failures which are sometime observed
when tests use the wildcard address to bind their test servers.
These changes are IpV6-only friendly.
best regards,
-- daniel
