Updated webrev at: http://cr.openjdk.java.net/~michaelm/8179559/webrev.2/
The tests have not changed from previous webrev.
Thanks,
Michael
On 05/05/2017, 15:20, Michael McMahon wrote:
Hi Mark,
It's certainly arguable that the OS should return the same address
that was configured.
But, I think we can work around that limitation regardless.
Since I sent the first webrev, I found a bug in
NetworkInterface.getByInetAddress()
and after fixing that, the MulticastSocket code does not need to change.
I'll send an updated webrev later.
Thanks
Michael.
On 05/05/2017, 14:52, Mark Sheppard wrote:
If we look at the failure scenario then it seen that
with multiple network interfaces having IPv6 and IPv4 configurations,
where the IPv6 part is not fully configured and is not UP, but is
RUNNING
wrt the change in MulticastSocket, is there not a deeper issue here?
that is, in the MulticastSocket.getInterface() method the invocation
InetAddress ia = (InetAddress)
getImpl().getOption(SocketOptions.IP_MULTICAST_IF)
doesn't return the same address as that which was set by the
MulticastSocket.setInterface()
in the problematic configurations the IPv6 interface is not UP, but
it is RUNNING, MULTICAST, and
the address is unspecified. It would be expected that the OS would
return the address configured in the
previous setsockopt?
At least it would be assumed that the OS syscall would be using the
state of the interface
as criteria to avoid returning the unspecified IPv6 address in
preference to the UP and RUNNING and selected IPv4 address?
It seems the OS preference is for IPv6 regardless of the state on the
interface.
Is there an issue to be raised with Solaris OS ?
Additionally, wrt the try block incorporating the address search by
iterating over the network interfaces, the catch clause will return ia
That is, the address retrieved with via the previous getOption
invocation.
Should this not return null or even re-throw the Exception?
returning an Address in this case seems questionable.
with respect to the change in MulticastSocket/Test.java
should the address checks be considered as OS agnostic?
a number of multicast socket tests exclude the network interface
unspecified address
and the loopback address for consideration.
regards
Mark
On 05/05/2017 11:02, Chris Hegarty wrote:
On 5 May 2017, at 10:23, Michael McMahon
<michael.x.mcma...@oracle.com> wrote:
Could I get the following changed reviewed please?
It's a fix for the two Solaris Multicast socket tests that fail
always.
http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/
This looks ok to me Michael. Good to have this loooooooooong standing
issue finally addressed. Thank you.
-Chris.
