> On 5 May 2017, at 18:36, Michael McMahon wrote:
>
>
>
> On 05/05/2017, 18:30, Chris Hegarty wrote:
>>> On 5 May 2017, at 18:29, Michael McMahon
>>> wrote:
>>> ...
>>>
>>> Do you mean if the Inet6Address passed in has zero for the scope_id that the
>>> search should ignore it, and do what
On 05/05/2017, 18:30, Chris Hegarty wrote:
On 5 May 2017, at 18:29, Michael McMahon wrote:
...
Do you mean if the Inet6Address passed in has zero for the scope_id that the
search should ignore it, and do what happens now, ie. return the first address
found?
Yes, that is what I wanted to say
> On 5 May 2017, at 18:29, Michael McMahon wrote:
> ...
>
> Do you mean if the Inet6Address passed in has zero for the scope_id that the
> search should ignore it, and do what happens now, ie. return the first
> address found?
Yes, that is what I wanted to say. Does it make sense?
-Chris.
On 05/05/2017, 18:14, Chris Hegarty wrote:
On 5 May 2017, at 16:19, Michael McMahon wrote:
Updated webrev at: http://cr.openjdk.java.net/~michaelm/8179559/webrev.2/
InetAddress.scope_id is optional ( 0 if unset ), should the code
only use it if it is non-zero?
-Chris.
Do you mean if the I
> On 5 May 2017, at 16:19, Michael McMahon wrote:
>
> Updated webrev at: http://cr.openjdk.java.net/~michaelm/8179559/webrev.2/
InetAddress.scope_id is optional ( 0 if unset ), should the code
only use it if it is non-zero?
-Chris.
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 thi
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 doe
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 MulticastSocke
Actually, I've just realised that the root cause is a more basic problem
in the
implementation of NetworkInterface.getByInetAddress() where it was not
checking the scopeids and therefore not distinguishing
::0%3 from ::0%4 etc
So, a better fix is actually in the implementation of that method. I
> On 5 May 2017, at 10:23, Michael McMahon 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 lo
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/
Thanks
Michael
11 matches
Mail list logo
