RFR: 8179559 Solaris MulticastSocket issues

[Michael McMahon]

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