Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
One comment so far. The ipv4mode parameter in getIPv4NetworkInterface() seems superfluous, with the call using parameter value "0" could be just elided to using the null return value directly. I was a bit confused also that the new function is in the TwoStacks... module, but it seems this file contains native code common to both dual stack/two stacks mode. We probably should move this code to a different source file some time, but it might be useful to put a comment in at least to say that it is common to both modes. Michael On 15/09/13 12:34, Mark Sheppard wrote: Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual adapter/interface may not be configured with for IPv6. This causes a problem with the MulticastSocket.setNetworkInterface() and MulticastSocket.getNetworkInterface() methods. The solution focuses on adding and additional check on the individual interface for IPV6 enabling. The fallback position when an adapter is not configured for IPV6, is to handled it as IPV4, only. It should be noted that setting an Interface which does not have a valid IP address bound to it will result in a SocketException. As such, i the onus in on the application to supply a validly configured NetworkInterface object to the MulticastSocket.setNetworkInterface(). With this in mind, the set of Interfaces constructed for the associated test is based on the interface being up, multicast, and valid IP address configured. regards Mark
Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
Mark, From what I can see, I think the changes are correct. On 16/09/2013 11:10, Michael McMahon wrote: One comment so far. The ipv4mode parameter in getIPv4NetworkInterface() seems superfluous, with the call using parameter value "0" could be just elided to using the null return value directly. I think the param is needed to determine if the function should ever return NULL, or force creation of the NI instance. From what I can see, Mark's changes preserve the same behavior by using this param. I was a bit confused also that the new function is in the TwoStacks... module, but it seems this file contains native code common to both dual stack/two stacks mode. We probably should move this code to a different source file some time, but it might be useful to put a comment in at least to say that it is common to both modes. I'm not sure what what code you are referring to here, but as far as I am aware there is no dual stack code in this file. Yes, there is both IPv4 and IPv6, but both should be on separate sockets. -Chris. Michael On 15/09/13 12:34, Mark Sheppard wrote: Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual adapter/interface may not be configured with for IPv6. This causes a problem with the MulticastSocket.setNetworkInterface() and MulticastSocket.getNetworkInterface() methods. The solution focuses on adding and additional check on the individual interface for IPV6 enabling. The fallback position when an adapter is not configured for IPV6, is to handled it as IPV4, only. It should be noted that setting an Interface which does not have a valid IP address bound to it will result in a SocketException. As such, i the onus in on the application to supply a validly configured NetworkInterface object to the MulticastSocket.setNetworkInterface(). With this in mind, the set of Interfaces constructed for the associated test is based on the interface being up, multicast, and valid IP address configured. regards Mark
Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
Hi Michael,
thanks for the response.
the getIPv4NetworkInterface is called in two places within the
getMulticastInterface function. It's a refactoring of what would have been
duplicate code. This lead to the "boolean" ipv4Mode.
line 2039
if (isIPV4) {
jobject netObject = NULL; // return is either an addr or a netif
netObject = getIPv4NetworkInterface(env, this, fd, opt, 1);
return netObject;
}
and
line 2134
return addr;
} else if (index == 0) {
jobject netObject = NULL;
netObject = getIPv4NetworkInterface(env, this, fd, opt, 0);
if (netObject != NULL) {
return netObject;
}
}
in the former the return will either be a always be an object, which
may have a null NetworkInterface object
in the latter it maybe null value in which case this branch of the code
fabricates
a null NetworkInterface object. The calling sequence here is for IPv6 and
is slightly different than that for IPv4.
hence the use of ipv4Mode indicator in getIPv4NetworkInterface function.
I'll add some comments as suggested
regards
Mark
On 16/09/2013 11:10, Michael McMahon wrote:
One comment so far. The ipv4mode parameter in
getIPv4NetworkInterface()
seems superfluous, with the call using parameter value "0"
could be just elided to using the null return value directly.
I was a bit confused also that the new function is in the TwoStacks...
module,
but it seems this file contains native code common to both dual
stack/two stacks
mode. We probably should move this code to a different source file
some time,
but it might be useful to put a comment in at least to say that it is
common
to both modes.
Michael
On 15/09/13 12:34, Mark Sheppard wrote:
Hi
please oblige and review the webrev below which addresses the issue
problem:
https://bugs.openjdk.java.net/browse/JDK-6458027
webrev:
http://cr.openjdk.java.net/~msheppar/6458027/webrev/
the core of the issue is that a windows platform may be IPv6 enabled,
but
an individual adapter/interface may not be configured with for IPv6.
This causes a problem with the MulticastSocket.setNetworkInterface()
and MulticastSocket.getNetworkInterface() methods.
The solution focuses on adding and additional check on the
individual interface for IPV6 enabling.
The fallback position when an adapter is not configured for IPV6, is to
handled it as IPV4, only.
It should be noted that setting an Interface which does not have a
valid IP address bound to it will result in a SocketException. As
such, i
the onus in on the application to supply a validly configured
NetworkInterface object to the MulticastSocket.setNetworkInterface().
With this in mind, the set of Interfaces constructed for the
associated test
is based on the interface being up, multicast, and valid IP address
configured.
regards
Mark
Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
Thanks Chris more lucid than my own reply Mark On 16/09/2013 11:33, Chris Hegarty wrote: Mark, From what I can see, I think the changes are correct. On 16/09/2013 11:10, Michael McMahon wrote: One comment so far. The ipv4mode parameter in getIPv4NetworkInterface() seems superfluous, with the call using parameter value "0" could be just elided to using the null return value directly. I think the param is needed to determine if the function should ever return NULL, or force creation of the NI instance. From what I can see, Mark's changes preserve the same behavior by using this param. I was a bit confused also that the new function is in the TwoStacks... module, but it seems this file contains native code common to both dual stack/two stacks mode. We probably should move this code to a different source file some time, but it might be useful to put a comment in at least to say that it is common to both modes. I'm not sure what what code you are referring to here, but as far as I am aware there is no dual stack code in this file. Yes, there is both IPv4 and IPv6, but both should be on separate sockets. -Chris. Michael On 15/09/13 12:34, Mark Sheppard wrote: Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual adapter/interface may not be configured with for IPv6. This causes a problem with the MulticastSocket.setNetworkInterface() and MulticastSocket.getNetworkInterface() methods. The solution focuses on adding and additional check on the individual interface for IPV6 enabling. The fallback position when an adapter is not configured for IPV6, is to handled it as IPV4, only. It should be noted that setting an Interface which does not have a valid IP address bound to it will result in a SocketException. As such, i the onus in on the application to supply a validly configured NetworkInterface object to the MulticastSocket.setNetworkInterface(). With this in mind, the set of Interfaces constructed for the associated test is based on the interface being up, multicast, and valid IP address configured. regards Mark
Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
On 16/09/13 11:33, Chris Hegarty wrote: Mark, From what I can see, I think the changes are correct. On 16/09/2013 11:10, Michael McMahon wrote: One comment so far. The ipv4mode parameter in getIPv4NetworkInterface() seems superfluous, with the call using parameter value "0" could be just elided to using the null return value directly. I think the param is needed to determine if the function should ever return NULL, or force creation of the NI instance. From what I can see, Mark's changes preserve the same behavior by using this param. Right. I missed the return statement just before. I was a bit confused also that the new function is in the TwoStacks... module, but it seems this file contains native code common to both dual stack/two stacks mode. We probably should move this code to a different source file some time, but it might be useful to put a comment in at least to say that it is common to both modes. I'm not sure what what code you are referring to here, but as far as I am aware there is no dual stack code in this file. Yes, there is both IPv4 and IPv6, but both should be on separate sockets. yep. Forget that as well. I thought it was being called from common code. So, I'm missing how this code is relevant then on Vista, which should be using the dual stack implementation then ? Michael -Chris. Michael On 15/09/13 12:34, Mark Sheppard wrote: Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual adapter/interface may not be configured with for IPv6. This causes a problem with the MulticastSocket.setNetworkInterface() and MulticastSocket.getNetworkInterface() methods. The solution focuses on adding and additional check on the individual interface for IPV6 enabling. The fallback position when an adapter is not configured for IPV6, is to handled it as IPV4, only. It should be noted that setting an Interface which does not have a valid IP address bound to it will result in a SocketException. As such, i the onus in on the application to supply a validly configured NetworkInterface object to the MulticastSocket.setNetworkInterface(). With this in mind, the set of Interfaces constructed for the associated test is based on the interface being up, multicast, and valid IP address configured. regards Mark
Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
Not sure about Vista per se ... Initially I ran the test case on windows 7 and the same failures existed so on analysis and tracing lead me to the TwoStackPlainDatagramSocketImpl I'm dependent on JPRT to handle the vista case ... if a Vista box exists I can run the test explicitly on it to ensure nothing has been overlooked? But, from my analysis the issue appeared to be the case that the ipv6_available is an OS level check, and this is insufficient as the individual adapters/interfaces may not be configured for IPv6, and so are handled as IPv4 interfaces. regards Mark On 16/09/2013 12:11, Michael McMahon wrote: On 16/09/13 11:33, Chris Hegarty wrote: Mark, From what I can see, I think the changes are correct. On 16/09/2013 11:10, Michael McMahon wrote: One comment so far. The ipv4mode parameter in getIPv4NetworkInterface() seems superfluous, with the call using parameter value "0" could be just elided to using the null return value directly. I think the param is needed to determine if the function should ever return NULL, or force creation of the NI instance. From what I can see, Mark's changes preserve the same behavior by using this param. Right. I missed the return statement just before. I was a bit confused also that the new function is in the TwoStacks... module, but it seems this file contains native code common to both dual stack/two stacks mode. We probably should move this code to a different source file some time, but it might be useful to put a comment in at least to say that it is common to both modes. I'm not sure what what code you are referring to here, but as far as I am aware there is no dual stack code in this file. Yes, there is both IPv4 and IPv6, but both should be on separate sockets. yep. Forget that as well. I thought it was being called from common code. So, I'm missing how this code is relevant then on Vista, which should be using the dual stack implementation then ? Michael -Chris. Michael On 15/09/13 12:34, Mark Sheppard wrote: Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual adapter/interface may not be configured with for IPv6. This causes a problem with the MulticastSocket.setNetworkInterface() and MulticastSocket.getNetworkInterface() methods. The solution focuses on adding and additional check on the individual interface for IPV6 enabling. The fallback position when an adapter is not configured for IPV6, is to handled it as IPV4, only. It should be noted that setting an Interface which does not have a valid IP address bound to it will result in a SocketException. As such, i the onus in on the application to supply a validly configured NetworkInterface object to the MulticastSocket.setNetworkInterface(). With this in mind, the set of Interfaces constructed for the associated test is based on the interface being up, multicast, and valid IP address configured. regards Mark
Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
On 16/09/2013 12:11, Michael McMahon wrote: ... yep. Forget that as well. I thought it was being called from common code. So, I'm missing how this code is relevant then on Vista, which should be using the dual stack implementation then ? Multicasting on Windows still uses the two stack implementation :-( http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip//src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java#129 -Chris. Michael -Chris. Michael On 15/09/13 12:34, Mark Sheppard wrote: Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual adapter/interface may not be configured with for IPv6. This causes a problem with the MulticastSocket.setNetworkInterface() and MulticastSocket.getNetworkInterface() methods. The solution focuses on adding and additional check on the individual interface for IPV6 enabling. The fallback position when an adapter is not configured for IPV6, is to handled it as IPV4, only. It should be noted that setting an Interface which does not have a valid IP address bound to it will result in a SocketException. As such, i the onus in on the application to supply a validly configured NetworkInterface object to the MulticastSocket.setNetworkInterface(). With this in mind, the set of Interfaces constructed for the associated test is based on the interface being up, multicast, and valid IP address configured. regards Mark
Re: RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems
On 16/09/13 13:53, Chris Hegarty wrote: On 16/09/2013 12:11, Michael McMahon wrote: ... yep. Forget that as well. I thought it was being called from common code. So, I'm missing how this code is relevant then on Vista, which should be using the dual stack implementation then ? Multicasting on Windows still uses the two stack implementation :-( http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip//src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java#129 Okay. Got you now. Thanks Michael -Chris. Michael -Chris. Michael On 15/09/13 12:34, Mark Sheppard wrote: Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual adapter/interface may not be configured with for IPv6. This causes a problem with the MulticastSocket.setNetworkInterface() and MulticastSocket.getNetworkInterface() methods. The solution focuses on adding and additional check on the individual interface for IPV6 enabling. The fallback position when an adapter is not configured for IPV6, is to handled it as IPV4, only. It should be noted that setting an Interface which does not have a valid IP address bound to it will result in a SocketException. As such, i the onus in on the application to supply a validly configured NetworkInterface object to the MulticastSocket.setNetworkInterface(). With this in mind, the set of Interfaces constructed for the associated test is based on the interface being up, multicast, and valid IP address configured. regards Mark
hg: jdk8/tl/langtools: 8021112: Spurious unchecked warning reported by javac; ...
Changeset: 4ce8148ffc4f Author:jlahoda Date: 2013-09-16 14:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ce8148ffc4f 8021112: Spurious unchecked warning reported by javac 6480588: No way to suppress deprecation warnings when implementing deprecated interface Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/depDocComment/SuppressDeprecation.out ! test/tools/javac/warnings/6594914/T6594914a.out ! test/tools/javac/warnings/6594914/T6594914b.out + test/tools/javac/warnings/suppress/ImplicitTest.java + test/tools/javac/warnings/suppress/ImplicitTest.out + test/tools/javac/warnings/suppress/PackageInfo.java + test/tools/javac/warnings/suppress/PackageInfo.out + test/tools/javac/warnings/suppress/T6480588.java + test/tools/javac/warnings/suppress/T6480588.out + test/tools/javac/warnings/suppress/T8021112a.java + test/tools/javac/warnings/suppress/T8021112b.java + test/tools/javac/warnings/suppress/T8021112b.out + test/tools/javac/warnings/suppress/TypeAnnotations.java + test/tools/javac/warnings/suppress/TypeAnnotations.out + test/tools/javac/warnings/suppress/VerifySuppressWarnings.java + test/tools/javac/warnings/suppress/pack/DeprecatedClass.java + test/tools/javac/warnings/suppress/pack/ImplicitMain.java + test/tools/javac/warnings/suppress/pack/ImplicitUse.java + test/tools/javac/warnings/suppress/pack/package-info.java
hg: jdk8/tl/jdk: 6458027: Disabling IPv6 on a specific network interface causes problems
Changeset: db0fc2b71298 Author:msheppar Date: 2013-09-16 14:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db0fc2b71298 6458027: Disabling IPv6 on a specific network interface causes problems Summary: added a check to test if an interface is configured for IPv6 to native code TwoStacklainDatagramSocketImpl: getMulticastInterface, setMulticastInterface Reviewed-by: chegar, michaelm ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c + test/java/net/MulticastSocket/SetGetNetworkInterfaceTest.java
