RFR: 8179559 Solaris MulticastSocket issues

[Mark Sheppard]

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.mcmahon at 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.