Re: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
On 02/05/2019 10:33, Andre Naujoks wrote: : I just wanted to notify you, that the whole issue with binding to a multicast address is not Linux specific. Understood as it's always been platform specific as to whether you could bind to a multicast address. This is one of the reason why we've had a recommendation in the API docs for several years to bind to the wildcard address and use the join methods to join the multicast group. This helps with the portability but has been problematic on Linux due to the "interference" issue. We had hoped that IP_MULTICAST_ALL had solved that but alas no. Once IPV6_MULTICAST_ALL is more widely available then we should try to make use of it. We are currently trying to reproduce the original issue with the reception of all multicast traffic on windows and will get back to you about that. Thanks, I don't think we've seen this issue on any other platforms. -Alan
Re: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol can override default handler
On 2019-05-02 15:20, Seán Coffey wrote: Hi Claes, Yes - looks like a fine suggestion. http://cr.openjdk.java.net/~coffeys/webrev.8217364.03/webrev/ Looks good to me.. ;-) /Claes
Re: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol can override default handler
Hi Claes,
Yes - looks like a fine suggestion.
http://cr.openjdk.java.net/~coffeys/webrev.8217364.03/webrev/
regards,
Sean.
On 02/05/2019 13:15, Claes Redestad wrote:
Hi Seán,
wouldn't it be more straightforward then to keep the logic intact and
skip the custom factory invocation in both cases if the protocol is
non-overrideable?
I.e., something like this:
diff -r 290283590646 src/java.base/share/classes/java/net/URL.java
--- a/src/java.base/share/classes/java/net/URL.java Tue Apr 30
23:47:00 2019 +0200
+++ b/src/java.base/share/classes/java/net/URL.java Thu May 02
14:10:57 2019 +0200
@@ -1403,8 +1403,9 @@
URLStreamHandlerFactory fac;
boolean checkedWithFactory = false;
+ boolean overrideableProtocol = isOverrideable(protocol);
- if (isOverrideable(protocol) &&
jdk.internal.misc.VM.isBooted()) {
+ if (overrideableProtocol && jdk.internal.misc.VM.isBooted()) {
// Use the factory (if any). Volatile read makes
// URLStreamHandlerFactory appear fully initialized to
current thread.
fac = factory;
@@ -1440,7 +1441,7 @@
// Check with factory if another thread set a
// factory since our last check
- if (!checkedWithFactory && (fac = factory) != null) {
+ if (overrideableProtocol && !checkedWithFactory && (fac =
factory) != null) {
handler2 = fac.createURLStreamHandler(protocol);
}
Thanks!
/Claes
On 2019-05-02 12:33, Seán Coffey wrote:
with webrev:
https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/
regards,
Sean.
On 02/05/2019 11:00, Seán Coffey wrote:
Been thinking a bit more about this one.
Given that only initialization code will traverse through the "if
(!isOverrideable(protocol))" check, I think we can add
synchronization to eliminate any timing scenarios where the handlers
Hashtable gets populated via another thread after we make the first
handers.get call in getURLStreamHandler(String protocol)
regards,
Sean.
On 30/04/2019 18:19, Seán Coffey wrote:
Looking to correct an issue that arose during the JDK-8213942 fix.
https://bugs.openjdk.java.net/browse/JDK-8217364
https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/
regards,
Sean.
Re: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol can override default handler
Hi Seán,
wouldn't it be more straightforward then to keep the logic intact and
skip the custom factory invocation in both cases if the protocol is
non-overrideable?
I.e., something like this:
diff -r 290283590646 src/java.base/share/classes/java/net/URL.java
--- a/src/java.base/share/classes/java/net/URL.java Tue Apr 30 23:47:00
2019 +0200
+++ b/src/java.base/share/classes/java/net/URL.java Thu May 02 14:10:57
2019 +0200
@@ -1403,8 +1403,9 @@
URLStreamHandlerFactory fac;
boolean checkedWithFactory = false;
+boolean overrideableProtocol = isOverrideable(protocol);
-if (isOverrideable(protocol) && jdk.internal.misc.VM.isBooted()) {
+if (overrideableProtocol && jdk.internal.misc.VM.isBooted()) {
// Use the factory (if any). Volatile read makes
// URLStreamHandlerFactory appear fully initialized to
current thread.
fac = factory;
@@ -1440,7 +1441,7 @@
// Check with factory if another thread set a
// factory since our last check
-if (!checkedWithFactory && (fac = factory) != null) {
+if (overrideableProtocol && !checkedWithFactory && (fac =
factory) != null) {
handler2 = fac.createURLStreamHandler(protocol);
}
Thanks!
/Claes
On 2019-05-02 12:33, Seán Coffey wrote:
with webrev: https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/
regards,
Sean.
On 02/05/2019 11:00, Seán Coffey wrote:
Been thinking a bit more about this one.
Given that only initialization code will traverse through the "if
(!isOverrideable(protocol))" check, I think we can add synchronization
to eliminate any timing scenarios where the handlers Hashtable gets
populated via another thread after we make the first handers.get call
in getURLStreamHandler(String protocol)
regards,
Sean.
On 30/04/2019 18:19, Seán Coffey wrote:
Looking to correct an issue that arose during the JDK-8213942 fix.
https://bugs.openjdk.java.net/browse/JDK-8217364
https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/
regards,
Sean.
Re: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol can override default handler
with webrev: https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/ regards, Sean. On 02/05/2019 11:00, Seán Coffey wrote: Been thinking a bit more about this one. Given that only initialization code will traverse through the "if (!isOverrideable(protocol))" check, I think we can add synchronization to eliminate any timing scenarios where the handlers Hashtable gets populated via another thread after we make the first handers.get call in getURLStreamHandler(String protocol) regards, Sean. On 30/04/2019 18:19, Seán Coffey wrote: Looking to correct an issue that arose during the JDK-8213942 fix. https://bugs.openjdk.java.net/browse/JDK-8217364 https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/ regards, Sean.
Re: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol can override default handler
Been thinking a bit more about this one. Given that only initialization code will traverse through the "if (!isOverrideable(protocol))" check, I think we can add synchronization to eliminate any timing scenarios where the handlers Hashtable gets populated via another thread after we make the first handers.get call in getURLStreamHandler(String protocol) http://gbr10227.uk.oracle.com/html/ws/jdk-jdk/open/webrev.8217364.02/webrev/ regards, Sean. On 30/04/2019 18:19, Seán Coffey wrote: Looking to correct an issue that arose during the JDK-8213942 fix. https://bugs.openjdk.java.net/browse/JDK-8217364 https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/ regards, Sean.
Re: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
Am 02.05.19 um 10:25 schrieb Alan Bateman: > On 02/05/2019 08:44, Andre Naujoks wrote: >> Hello all. >> >> I just noticed, that the fix from Bug JDK-8210493 was reverted for Java >> 12. With a new bug JDK-8215294 taking over the issue. > Yes, it caused problems so had to be reverted. In addition to > JDK-8215294 there is also JDK-8216417 which we expect to set the scopeID > when binding a TCP socket to an IPv6 link-local address. > >> >> Just to let you know, the issue is not linux specific (as the new bug >> states). A test on a windows machine resulted in the same behavior. > The portability recommendation in the javadoc is to bind to the wildcard > address. Yes, you might have issues on several platforms when trying to > bind to an IPv6 multicast address when the scopeID is not set. > (If I recall correctly, the original issue that Hendrik brought up here > was binding to the multicast address to avoid interference on Linux. We > thought we had that addressed with IP_MULTICAST_ALL but it turns not to > be effective with IPv6 sockets. I believe there is a patch for that or a > proposal to introduce an equivalent IPV6_MULTICAST_ALL). Yes, I wrote that patch. It is part of Linux 4.20 [1]. It should be a viable workaround for Java on Linux from that version onward. It just takes a while until the fix arrives in distributions (I am on Debian unstable and not yet on a fixed kernel-version.). I just wanted to notify you, that the whole issue with binding to a multicast address is not Linux specific. We are currently trying to reproduce the original issue with the reception of all multicast traffic on windows and will get back to you about that. Andre [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=15033f0457dca569b284bef0c8d3ad55fb37eacb > > -Alan.
Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support
Hi Arthur, On the surface, this looks good. However I have a concern about two things: 1. IPSupport needs to read system properties, attempts to bind sockets etc... I wonder how that might interact with tests that use a security manager, as some of these operations may throw a SecurityException. Maybe some double checking would be in order for those. 2. I would also be more comfortable if skipIfCurrentConfigurationIsInvalid() (and possibly the static initializer too?), could throw an AssertionError if it finds that neither IPv4 nor IPv6 are available on a system. I'm concerned that a bug that e.g. prevents to bind any socket would go unnoticed if all tests are skipped... best regards, -- daniel PS: Just a heads up that I have a pending fix [1] which I'm intending to push later today and which also touches some of the tests from your patch. Hopefully any merge should be trivial. [1] https://mail.openjdk.java.net/pipermail/net-dev/2019-April/012416.html On 01/05/2019 23:21, Arthur Eubanks wrote: Sorry for the delay, but here's the next revision: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.01 The list of tests modified was found by searching for "preferIPv4Stack" in the tests. The only one I didn't touch was test/jdk/sun/net/sdp/sanity.sh, which is a shell test, and is Solaris-only. For most tests, all I did was add IPSupport.skipIfCurrentConfigurationIsInvalid(). Some of them also had custom implementations for detecting if IPv6 was available, so I replaced those with the new IPSupport version. Also added a missing "@test" to test/jdk/java/net/Socket/RST.java. Again, I made sure that the only time the test is skipped with IPSupport.skipIfCurrentConfigurationIsInvalid() is when IPv4 is not available (with LD_PRELOAD) and when java.net.preferIPv4Stack is true. There are still tests that fail/timeout under the LD_PRELOAD that intercepts and rejects IPv4 calls to getifaddrs(), setsockopt(), and socket(), but those will be fixed in the future, likely with changes to the JDK itself.
Re: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
On 02/05/2019 08:44, Andre Naujoks wrote: Hello all. I just noticed, that the fix from Bug JDK-8210493 was reverted for Java 12. With a new bug JDK-8215294 taking over the issue. Yes, it caused problems so had to be reverted. In addition to JDK-8215294 there is also JDK-8216417 which we expect to set the scopeID when binding a TCP socket to an IPv6 link-local address. Just to let you know, the issue is not linux specific (as the new bug states). A test on a windows machine resulted in the same behavior. The portability recommendation in the javadoc is to bind to the wildcard address. Yes, you might have issues on several platforms when trying to bind to an IPv6 multicast address when the scopeID is not set. (If I recall correctly, the original issue that Hendrik brought up here was binding to the multicast address to avoid interference on Linux. We thought we had that addressed with IP_MULTICAST_ALL but it turns not to be effective with IPv6 sockets. I believe there is a patch for that or a proposal to introduce an equivalent IPV6_MULTICAST_ALL). -Alan.
IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
Hello all. I just noticed, that the fix from Bug JDK-8210493 was reverted for Java 12. With a new bug JDK-8215294 taking over the issue. Just to let you know, the issue is not linux specific (as the new bug states). A test on a windows machine resulted in the same behavior. Andre ### win10, openjdk12 Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App printProperties INFO: awt.toolkit: sun.awt.windows.WToolkit file.encoding: Cp1252 file.separator: \ java.awt.graphicsenv: sun.awt.Win32GraphicsEnvironment java.class.path: TestIPv6-1.0.0-SNAPSHOT.jar java.class.version: 56.0 java.home: C:\Program Files\Java\jdk-12.0.1 java.io.tmpdir: C:\Users\WUENSC~1\AppData\Local\Temp\ java.library.path: C:\Program Files\Java\jdk-12.0.1\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Users\wuenschmann\bin;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\local\bin;C:\Program Files\Git\usr\bin;C:\Program Files\Git\usr\bin;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;U:\bin;C:\Users\wuenschmann\coding\cygwin\bin;C:\Users\wuenschmann\coding\apache-maven-3.6.1;C:\Users\wuenschmann\coding\apache-maven-3.6.1\bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\iCLS;C:\Program Files\Intel\Intel(R) Management Engine Components\iCLS;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files\Git\cmd;C:\Program Files\PuTTY;C:\Program Files\Java\jdk-12.0.1;C:\Users\wuenschmann\AppData\Local\Microsoft\WindowsApps;C:\Users\wuenschmann\AppData\Local\atom\bin;C:\Program Files\Git\usr\bin\vendor_perl;C:\Program Files\Git\usr\bin\core_perl;. java.runtime.name: OpenJDK Runtime Environment java.runtime.version: 12.0.1+12 java.specification.name: Java Platform API Specification java.specification.vendor: Oracle Corporation java.specification.version: 12 java.vendor: Oracle Corporation java.vendor.url: https://java.oracle.com/ java.vendor.url.bug: https://bugreport.java.com/bugreport/ java.version: 12.0.1 java.version.date: 2019-04-16 java.vm.compressedOopsMode: Zero based java.vm.info: mixed mode, sharing java.vm.name: OpenJDK 64-Bit Server VM java.vm.specification.name: Java Virtual Machine Specification java.vm.specification.vendor: Oracle Corporation java.vm.specification.version: 12 java.vm.vendor: Oracle Corporation java.vm.version: 12.0.1+12 jdk.debug: release line.separator: os.arch: amd64 os.name: Windows 10 os.version: 10.0 path.separator: ; sun.arch.data.model: 64 sun.boot.library.path: C:\Program Files\Java\jdk-12.0.1\bin sun.cpu.endian: little sun.cpu.isalist: amd64 sun.desktop: windows sun.io.unicode.encoding: UnicodeLittle sun.java.command: TestIPv6-1.0.0-SNAPSHOT.jar sun.java.launcher: SUN_STANDARD sun.jnu.encoding: Cp1252 sun.management.compiler: HotSpot 64-Bit Tiered Compilers sun.os.patch.level: user.country: DE user.dir: C:\Users\wuenschmann\EclipseProject\TestIPv6\target user.home: C:\Users\wuenschmann user.language: de user.name: wuenschmann user.script: user.variant: Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main INFO: Got network interface: eth0 - 2 Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main INFO: ScopeID: 2 Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main INFO: Bind to: /ff12:0:0:0:0:0:4749:4750%eth0:29550 Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main SEVERE: null java.net.BindException: Cannot assign requested address: bind at java.base/sun.nio.ch.Net.bind0(Native Method) at java.base/sun.nio.ch.Net.bind(Net.java:455) at java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814) at java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785) at de.nordsys.test.testipv6.App.main(App.java:152) Exception in thread "main" java.lang.Error: java.net.BindException: Cannot assign requested address: bind at de.nordsys.test.testipv6.App.main(App.java:160) Caused by: java.net.BindException: Cannot assign requested address: bind at java.base/sun.nio.ch.Net.bind0(Native Method) at java.base/sun.nio.ch.Net.bind(Net.java:455) at java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814) at java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785) at de.nordsys.test.testipv6.App.main(App.java:152) ### ubuntu-18.04, openjdk12: Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App printProperties INFO: awt.toolkit: sun.awt.X11.XToolkit file.encoding: UTF-8 file.separator: / java.awt.graphicsenv: sun.awt.X11GraphicsEnvironment java.class.path: TestIPv6-1.0.0-SNAPSHOT.jar java.class.version: 56.0 java.home: /usr/lib/jvm/jdk-12.0.1 jav
