[13u, 11u] RFR: 8236441: Bound MulticastSocket fails when setting outbound interface on Windows
Alex Kashchenko
akashche at redhat.com
Wed Apr 29 14:19:22 UTC 2020
Hi,
Please review backports of 8236441 to 13u and 11u:
Bug: https://bugs.openjdk.java.net/browse/JDK-8236441
Original change: https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde
Original review thread:
https://mail.openjdk.java.net/pipermail/net-dev/2019-December/013458.html
Patches to NetworkInterface_winXP.c and
TwoStacksPlainDatagramSocketImpl.c apply cleanly to both 13u and 11u.
Minor changes were required for IPMulticastIF.java test.
13u webrev: https://cr.openjdk.java.net/~akasko/jdk13u/8236441/webrev.00/
Test is changed in 13 because behaviour of getOption(IP_MULTICAST_IF)
was changed in 14 in JDK-8233307 [1]. So in testGetOptionBound and
testGetOptionUnbound this line [2]:
assertEquals(ms.getOption(IP_MULTICAST_IF), null);
was changed to:
NetworkInterface ni = ms.getOption(IP_MULTICAST_IF);
if (null != ni) { // JDK-8233307: return value changed
assertEquals(ni.getName(), null);
}
11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8236441/webrev.00/
In addition to the change above, jdk.test.lib.net.IPSupport class was
added in 13 in 8220673 [3] and 8223652 [4]. It is not clear, whether
these changes to test code should be backported to 11u. In the webrev
above usage of IPSupport is removed (this line [5]). If it is preferred
to have these changes backported to 11 before 8236441 - please let me
know, I can work on backporting them.
Besides that, jdk.test.lib.NetworkConfiguration in 11u lacks
multicastInterfaces method that was added in 8207404 [6]. Likewise the
above, it is not clear whether this change should be backported to 11u,
so its call [7] is changed from:
nc.multicastInterfaces(true)
to:
Stream.concat(nc.ip4MulticastInterfaces(),
nc.ip6MulticastInterfaces()).distinct()
Testing: test is included with the patch, also ran regression and
compatibility tests for MulticastSocket.
PS: regarding 13u, it is not clear, what would be the correct process
for such backports: whether it should be backported to 13 first and to
11 only after that, whether it should go to 13 at all (P2 issue, but not
security related) etc. From the local backporting process point of view,
checking the patch with 13 first, and then moving to 11 and 8 seems to
be the most convenient.
[1] https://bugs.openjdk.java.net/browse/JDK-8233307
[2] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.158
[3] https://bugs.openjdk.java.net/browse/JDK-8220673
[4] https://bugs.openjdk.java.net/browse/JDK-8223652
[5] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.59
[6] https://bugs.openjdk.java.net/browse/JDK-8207404
[7] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.69
--
-Alex
More information about the jdk-updates-dev
mailing list