From Alan.Bateman at oracle.com Mon Dec 2 18:33:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Dec 2019 18:33:47 +0000 Subject: 8235193: JDK-8235193,(dc) Remove JNI overhead from DatagramChannel.send implementation Message-ID: <29bc7ba3-105e-4325-773c-f56f433a3f35@oracle.com> JDK-8234805 removed the JNI upcalls from DatagramChannel.receive. This is a follow-up to improve the send method by eliminating the use of NET_InetAddressToSockaddr (lots of JNI calls) and replacing it with code to populate the socket address using the NativeSocketAddress implementation class added in JDK-8234805. The webrev with the changes is here. ??? http://cr.openjdk.java.net/~alanb/8235193/webrev/ -Alan From lance.andersen at oracle.com Tue Dec 3 00:59:31 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 2 Dec 2019 19:59:31 -0500 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file Message-ID: HI all, Please review the proposed fix for an issue with Zip FS where the permissions set on the Zip file are not retained when the Zip file is updated. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8229888/webrev.00/index.html Mach5 jdk-tier1, jdk-tier2, and jdk-tier3 run clean. Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From michael.x.mcmahon at oracle.com Tue Dec 3 09:59:18 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 3 Dec 2019 09:59:18 +0000 Subject: RFR 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() fails on Windows 10 Message-ID: <0848d7ec-dbc6-ddf8-85df-c561afbd4955@oracle.com> Could I get the following two trivial test case fixes reviewed please? They are both caused by a recent configuration change to Windows 10 where socket connect requests are attempted four times, at 500ms intervals, on connection refused errors, which means that such connects will take around 2 seconds to return to the caller. The two tests need to increase their timeout from 2 sec to 3 sec. 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() fails on Windows 10 http://cr.openjdk.java.net/~michaelm/8234823/webrev.1/ 8234823: java/nio/channels/SocketChannel/AdaptSocket.java fails on Windows 10 http://cr.openjdk.java.net/~michaelm/8234824/webrev.1/ There are links to the bug reports from the webrevs. Thanks, Michael. From Alan.Bateman at oracle.com Tue Dec 3 11:08:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Dec 2019 11:08:19 +0000 Subject: RFR 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() fails on Windows 10 In-Reply-To: <0848d7ec-dbc6-ddf8-85df-c561afbd4955@oracle.com> References: <0848d7ec-dbc6-ddf8-85df-c561afbd4955@oracle.com> Message-ID: On 03/12/2019 09:59, Michael McMahon wrote: > : > > 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() > fails on Windows 10 > http://cr.openjdk.java.net/~michaelm/8234823/webrev.1/ For this one, it should be okay to increase the timeout to a much larger timeout if you want. For example, if the connect timeout is 10s then it will still fail with ConnectException, you'll only get the SocketTimeoutException if it were to exceed 10s. > > 8234823: java/nio/channels/SocketChannel/AdaptSocket.java fails on > Windows 10 > http://cr.openjdk.java.net/~michaelm/8234824/webrev.1/ I think this one should be okay to increase to a much larger value too. -Alan From michael.x.mcmahon at oracle.com Tue Dec 3 11:36:41 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 3 Dec 2019 11:36:41 +0000 Subject: RFR 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() fails on Windows 10 In-Reply-To: References: <0848d7ec-dbc6-ddf8-85df-c561afbd4955@oracle.com> Message-ID: <96f3478d-7707-13c6-b255-17dace3e5dfc@oracle.com> Thanks Alan. Yes, I think it's reasonable to set a much larger timeout. The actual delay experienced (annoying as it is) will still be only two seconds. I'll go ahead with that. Michael. On 03/12/2019 11:08, Alan Bateman wrote: > On 03/12/2019 09:59, Michael McMahon wrote: >> : >> >> 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() >> fails on Windows 10 >> http://cr.openjdk.java.net/~michaelm/8234823/webrev.1/ > For this one, it should be okay to increase the timeout to a much > larger timeout if you want. For example, if the connect timeout is 10s > then it will still fail with ConnectException, you'll only get the > SocketTimeoutException if it were to exceed 10s. > >> >> 8234823: java/nio/channels/SocketChannel/AdaptSocket.java fails on >> Windows 10 >> http://cr.openjdk.java.net/~michaelm/8234824/webrev.1/ > I think this one should be okay to increase to a much larger value too. > > -Alan From Alan.Bateman at oracle.com Tue Dec 3 21:04:02 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Dec 2019 21:04:02 +0000 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: References: Message-ID: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> On 03/12/2019 00:59, Lance Andersen wrote: > HI all, > > Please review the proposed fix for an issue with Zip FS where the > permissions set on the Zip file are not retained when the Zip file is > updated. > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8229888/webrev.00/index.html > Testing the underlying FileStore to see if supports "posix" may be problematic or costly here as it requires finding the mount entry file the underlying file store. You should find that it is much more efficient to just call getPosixFileAttributes and catch UOE (using exceptions for control flow is not nice of course but you will avoid a lot of issues). In passing, I should mention that the non-stringy way to to check if POSIX file permissions are support is to invoke on supportsFileAttributeView(PosixFIleAttributeView.class). One other approach to look at is just letting Files.move copy the file attributes. It will copy file permissions and attempt to copy all other attributes (it only fails if it can't copy the basic file attributes to the file in its new location). Another point is that the Files.newOutputStream to create the file next to the original zip file can be created with initial file attributes. Combined with Files.move it means there is another way to do this. I only mention is because I assume there will be follow on issues to fix up other file attributes of the zip file that are lost when it is re-created. -Alan From lance.andersen at oracle.com Tue Dec 3 23:45:33 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 3 Dec 2019 18:45:33 -0500 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> Message-ID: <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> Thank you for the comments Alan. > On Dec 3, 2019, at 4:04 PM, Alan Bateman wrote: > > On 03/12/2019 00:59, Lance Andersen wrote: >> HI all, >> >> Please review the proposed fix for an issue with Zip FS where the permissions set on the Zip file are not retained when the Zip file is updated. >> >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8229888/webrev.00/index.html >> > Testing the underlying FileStore to see if supports "posix" may be problematic or costly here as it requires finding the mount entry file the underlying file store. You should find that it is much more efficient to just call getPosixFileAttributes Did you mean: Files.getPosixFilePermissions > and catch UOE (using exceptions for control flow is not nice of course but you will avoid a lot of issues). In passing, I should mention that the non-stringy way to to check if POSIX file permissions are support is to invoke on supportsFileAttributeView(PosixFIleAttributeView.class). Would the following be more efficient than catching the IOE as I saw it used in TempFileHelper: -------- boolean isPosix = FileSystems.getDefault().supportedFileAttributeViews().contains("posix"); -------- > > One other approach to look at is just letting Files.move copy the file attributes. It will copy file permissions and attempt to copy all other attributes (it only fails if it can't copy the basic file attributes to the file in its new location). Another point is that the Files.newOutputStream to create the file next to the original zip file can be created with initial file attributes. Combined with Files.move it means there is another way to do this. I only mention is because I assume there will be follow on issues to fix up other file attributes of the zip file that are lost when it is re-created. If I am understanding this suggestion, it would be to modify the call to Files.createTempFile in the method createTempFileinSameDirectoryAs to pass the original zip file permissions as an file attribute ? Best Lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From Alan.Bateman at oracle.com Wed Dec 4 09:11:35 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Dec 2019 09:11:35 +0000 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> Message-ID: On 03/12/2019 23:45, Lance Andersen wrote: > Did you mean: ?Files.getPosixFilePermissions Yes, there was a typo in my mail. > : > > Would the following be more efficient than catching the IOE as I saw > it used in TempFileHelper: > > -------- > boolean isPosix = > FileSystems.getDefault().supportedFileAttributeViews().contains("posix"); > -------- Yes, that also avoids needing to be concerned with the FileStore. > : > > If I am understanding this suggestion, it would be to modify the call > to Files.createTempFile in the method createTempFileinSameDirectoryAs > to pass the ?original zip file permissions as an file attribute ? Yes, although you will be restricted by the umask so you could end up with less permissions that the original zip file. Anyway, I just wanted to mention it as alternative ways that you could explore to avoid interacting with the underlying FileStore as I suspect that will be problematic in some environments. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Dec 4 16:09:26 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 Dec 2019 16:09:26 +0000 Subject: 8235193: JDK-8235193,(dc) Remove JNI overhead from DatagramChannel.send implementation In-Reply-To: <29bc7ba3-105e-4325-773c-f56f433a3f35@oracle.com> References: <29bc7ba3-105e-4325-773c-f56f433a3f35@oracle.com> Message-ID: Alan, On 02/12/2019 18:33, Alan Bateman wrote: > JDK-8234805 removed the JNI upcalls from DatagramChannel.receive. This > is a follow-up to improve the send method by eliminating the use of > NET_InetAddressToSockaddr (lots of JNI calls) and replacing it with code > to populate the socket address using the NativeSocketAddress > implementation class added in JDK-8234805. > > The webrev with the changes is here. > ??? http://cr.openjdk.java.net/~alanb/8235193/webrev/ I think that this is very good. I had the very same though ( of extending the use of NativeSocketAddress to send ) when I seen your patch that introduced it. Inet6Address::addressBytes returns a reference to the actual byte array that backs the Inet6Address. The method is package-private and only shared through a shared-secret, so it should be fine. I don't think that addressBytes should clone the address, just calling it out so that we're all on the same page and we pay attention to keeping it safe, if there is future refactoring in this area. -Chris. From Alan.Bateman at oracle.com Thu Dec 5 09:06:29 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Dec 2019 09:06:29 +0000 Subject: 8235193: JDK-8235193,(dc) Remove JNI overhead from DatagramChannel.send implementation In-Reply-To: References: <29bc7ba3-105e-4325-773c-f56f433a3f35@oracle.com> Message-ID: <586648aa-8b32-9fd7-e77a-dc0990ecf78e@oracle.com> On 04/12/2019 16:09, Chris Hegarty wrote: > : > > Inet6Address::addressBytes returns a reference to the actual byte > array that backs the Inet6Address. The method is package-private and > only shared through a shared-secret, so it should be fine. I don't > think that addressBytes should clone the address, just calling it out > so that we're all on the same page and we pay attention to keeping it > safe, if there is future refactoring in this area. Right, Inet6Address::addressBytes is needed so that the IPv6 address bytes can be copied efficiently into the native sockaddr. If someone were to make it public by accident then there would be a significant security issue so any refactoring in this area does need to be careful. -Alan From Alan.Bateman at oracle.com Thu Dec 5 19:59:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Dec 2019 19:59:56 +0000 Subject: Need help testing jdk-14+26 (or newer) if you are using DatagramChannel Message-ID: <3b46a9ec-3500-89fe-1e9b-537983477f0f@oracle.com> There are several significant changes to the DatagramChannel implementation in JDK 14 that we could do with help testing if anyone using this API has cycles. The main motivation for the recent changes in this area is to get closer to the point where we can replace the implementations of classic DatagramSocket and MulticastSocket. jdk-14+26 is the latest build [1], this has the recent changes to improve the performance of the send/receive methods that we discussed here. -Alan [1] http://jdk.java.net/14/ From michael.x.mcmahon at oracle.com Fri Dec 6 11:13:23 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 6 Dec 2019 11:13:23 +0000 Subject: RFR 8235475: Add additional timestamp to test java/nio/channels/Selector/SelectWithConsumer.java Message-ID: <0f79658a-8425-af96-7c9c-c2e5973f50c2@oracle.com> Hi, Could I get the following small instrumentation change to a test, reviewed please? It just adds some additional logging for the case when the test fails. Thanks, Michael. diff -r 4938269b8b17 test/jdk/java/nio/channels/Selector/SelectWithConsumer.java --- a/test/jdk/java/nio/channels/Selector/SelectWithConsumer.java Fri Dec 06 10:00:16 2019 +0100 +++ b/test/jdk/java/nio/channels/Selector/SelectWithConsumer.java Fri Dec 06 11:10:04 2019 +0000 @@ -454,10 +454,15 @@ ???????? // select(Consumer, timeout) ???????? try (Selector sel = Selector.open()) { +??????????? long pre = System.currentTimeMillis(); ???????????? scheduleClose(sel, 3, SECONDS); ???????????? long start = System.currentTimeMillis(); ???????????? int n = sel.select(k -> assertTrue(false), 60*1000); ???????????? long duration = System.currentTimeMillis() - start; +??? ??? if (duration < 2000) { +??? ??? // Test failed so log the various timestamps +??? ??? System.out.printf("pre=%d, start=%d, duration=%d\n", pre, start, duration); +??? ??? } ???????????? assertTrue(n == 0); ???????????? assertTrue(duration > 2000 && duration < 10*1000, ???????????????????? "select took " + duration + " ms"); From Alan.Bateman at oracle.com Fri Dec 6 11:27:00 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Dec 2019 11:27:00 +0000 Subject: RFR 8235475: Add additional timestamp to test java/nio/channels/Selector/SelectWithConsumer.java In-Reply-To: <0f79658a-8425-af96-7c9c-c2e5973f50c2@oracle.com> References: <0f79658a-8425-af96-7c9c-c2e5973f50c2@oracle.com> Message-ID: On 06/12/2019 11:13, Michael McMahon wrote: > Hi, > > Could I get the following small instrumentation change to a test, > reviewed please? > > It just adds some additional logging for the case when the test fails. The existing assert prints a message like this when it fails: java.lang.AssertionError: select took 1813 ms expected [true] but found [false] so probably better to expand the existing message so that the crumbs aren't split between the assert and a trace message sent to System.out. I suspect we will need to change this test to use System.nanoTimes, maybe for another issue. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Fri Dec 6 11:56:25 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 6 Dec 2019 11:56:25 +0000 Subject: RFR 8235475: Add additional timestamp to test java/nio/channels/Selector/SelectWithConsumer.java In-Reply-To: References: <0f79658a-8425-af96-7c9c-c2e5973f50c2@oracle.com> Message-ID: <73bbe2ba-3218-0f04-9361-4956201e4971@oracle.com> On 06/12/2019 11:27, Alan Bateman wrote: > On 06/12/2019 11:13, Michael McMahon wrote: >> Hi, >> >> Could I get the following small instrumentation change to a test, >> reviewed please? >> >> It just adds some additional logging for the case when the test fails. > The existing assert prints a message like this when it fails: > > java.lang.AssertionError: select took 1813 ms expected [true] but > found [false] > > so probably better to expand the existing message so that the crumbs > aren't split between the assert and a trace message sent to System.out. > > I suspect we will need to change this test to use System.nanoTimes, > maybe for another issue. > > -Alan > Ok, thanks! I'll push patch below. It's likely only a temporary change anyhow. I changed to use nanoTime in this test only, which should guarantee the highest millisecond resolution - Michael. diff -r 4938269b8b17 test/jdk/java/nio/channels/Selector/SelectWithConsumer.java --- a/test/jdk/java/nio/channels/Selector/SelectWithConsumer.java Fri Dec 06 10:00:16 2019 +0100 +++ b/test/jdk/java/nio/channels/Selector/SelectWithConsumer.java Fri Dec 06 11:52:28 2019 +0000 @@ -454,13 +454,17 @@ ???????? // select(Consumer, timeout) ???????? try (Selector sel = Selector.open()) { +??????????? long pre = System.nanoTime(); ???????????? scheduleClose(sel, 3, SECONDS); -??????????? long start = System.currentTimeMillis(); +??????????? long start = System.nanoTime(); ???????????? int n = sel.select(k -> assertTrue(false), 60*1000); -??????????? long duration = System.currentTimeMillis() - start; +??????????? long after = System.nanoTime(); +??????????? long duration = (after - start) / 1000000; +??????????? long scheduleDuration = (start - pre) / 1000000; ???????????? assertTrue(n == 0); ???????????? assertTrue(duration > 2000 && duration < 10*1000, -??????????????????? "select took " + duration + " ms"); +??????????????????? "select took " + duration + " ms schedule took " + +??????????????????? scheduleDuration + " ms"); ???????????? assertFalse(sel.isOpen()); ???????? } ???? } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Dec 6 12:12:57 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Dec 2019 12:12:57 +0000 Subject: RFR 8235475: Add additional timestamp to test java/nio/channels/Selector/SelectWithConsumer.java In-Reply-To: <73bbe2ba-3218-0f04-9361-4956201e4971@oracle.com> References: <0f79658a-8425-af96-7c9c-c2e5973f50c2@oracle.com> <73bbe2ba-3218-0f04-9361-4956201e4971@oracle.com> Message-ID: <3274f151-adef-9f06-beb0-b2dd230caadc@oracle.com> On 06/12/2019 11:56, Michael McMahon wrote: > > : > > I changed to use nanoTime in this test only, which should guarantee > the highest millisecond resolution > Okay although I think we will need a follow-on to change the other usages in this file so that we don't have a mix - can you create a follow-on issue? The patch creates inconsistencies in the naming. I think "pre" need to renamed to "before". It looks like "duration" needs to renamed too, probably to "selectDuration" so that we don't have a mix of naming conventions in this one test. -Alan. From michael.x.mcmahon at oracle.com Fri Dec 6 12:24:57 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 6 Dec 2019 12:24:57 +0000 Subject: RFR 8235475: Add additional timestamp to test java/nio/channels/Selector/SelectWithConsumer.java In-Reply-To: <3274f151-adef-9f06-beb0-b2dd230caadc@oracle.com> References: <0f79658a-8425-af96-7c9c-c2e5973f50c2@oracle.com> <73bbe2ba-3218-0f04-9361-4956201e4971@oracle.com> <3274f151-adef-9f06-beb0-b2dd230caadc@oracle.com> Message-ID: On 06/12/2019 12:12, Alan Bateman wrote: > On 06/12/2019 11:56, Michael McMahon wrote: >> >> : >> >> I changed to use nanoTime in this test only, which should guarantee >> the highest millisecond resolution >> > Okay although I think we will need a follow-on to change the other > usages in this file so that we don't have a mix - can you create a > follow-on issue? > JDK-8235481 - Change java/nio/channels/Selector/SelectWithConsumer.java to use System.nanoTime > The patch creates inconsistencies in the naming. I think "pre" need to > renamed to "before". It looks like "duration" needs to renamed too, > probably to "selectDuration" so that we don't have a mix of naming > conventions in this one test. > Okay, I'll change those. Thanks, Michael > -Alan. > From lance.andersen at oracle.com Mon Dec 9 18:28:56 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 9 Dec 2019 13:28:56 -0500 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> Message-ID: Here is a revised patch: http://cr.openjdk.java.net/~lancea/8229888/webrev.01/index.html . I spent some time trying leverage createTempFileinSameDirectoryAs but it was getting messy as this method is also used when creating temp files in a zip to zip copy. I might try to revisit this later but the above seemed more straight forwarded Best Lance > On Dec 3, 2019, at 6:45 PM, Lance Andersen wrote: > > Thank you for the comments Alan. > >> On Dec 3, 2019, at 4:04 PM, Alan Bateman > wrote: >> >> On 03/12/2019 00:59, Lance Andersen wrote: >>> HI all, >>> >>> Please review the proposed fix for an issue with Zip FS where the permissions set on the Zip file are not retained when the Zip file is updated. >>> >>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8229888/webrev.00/index.html >>> >> Testing the underlying FileStore to see if supports "posix" may be problematic or costly here as it requires finding the mount entry file the underlying file store. You should find that it is much more efficient to just call getPosixFileAttributes > Did you mean: Files.getPosixFilePermissions > >> and catch UOE (using exceptions for control flow is not nice of course but you will avoid a lot of issues). In passing, I should mention that the non-stringy way to to check if POSIX file permissions are support is to invoke on supportsFileAttributeView(PosixFIleAttributeView.class). > > > Would the following be more efficient than catching the IOE as I saw it used in TempFileHelper: > > -------- > boolean isPosix = FileSystems.getDefault().supportedFileAttributeViews().contains("posix"); > -------- > >> >> One other approach to look at is just letting Files.move copy the file attributes. It will copy file permissions and attempt to copy all other attributes (it only fails if it can't copy the basic file attributes to the file in its new location). Another point is that the Files.newOutputStream to create the file next to the original zip file can be created with initial file attributes. Combined with Files.move it means there is another way to do this. I only mention is because I assume there will be follow on issues to fix up other file attributes of the zip file that are lost when it is re-created. > > If I am understanding this suggestion, it would be to modify the call to Files.createTempFile in the method createTempFileinSameDirectoryAs to pass the original zip file permissions as an file attribute ? > > Best > Lance >> >> -Alan > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From Alan.Bateman at oracle.com Tue Dec 10 08:32:48 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Dec 2019 08:32:48 +0000 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> Message-ID: <0d162ed5-e64a-85f4-65ea-1cac7fd4bfaf@oracle.com> On 09/12/2019 18:28, Lance Andersen wrote: > Here is a revised patch: > http://cr.openjdk.java.net/~lancea/8229888/webrev.01/index.html. This version looks better but there are still a few points that need discussion. It's not clear to me why getPosixAttributes and setZipFileAttributes access the file system in privileged blocks. The jdk.zipfs has full access to the file system so I would have thought that access to the zip files should be restricted by the permissions of the caller. If restoring any of the file permissions, owner or group fails then sync will fail. That needs a bit more study to see if it make sense or not. If the original zip file is owned by someone else then I suspect you may have to truncate and re-write it as the chown/chgrp will likely fail and will fail after the the original file has been replaced. It may be that the move into place has to be visited and replaced with a truncate/re-write in some cases to cover all the cases that you want. -Alan From yunxing.cyx at alibaba-inc.com Tue Dec 10 13:30:13 2019 From: yunxing.cyx at alibaba-inc.com (=?UTF-8?B?6ZmI5LqR5pifKOS6keaDuik=?=) Date: Tue, 10 Dec 2019 21:30:13 +0800 Subject: =?UTF-8?B?c3VwcG9ydCBBc3luY2hyb25vdXMgSU8gb24gTGludXg=?= In-Reply-To: <552b24e6-6782-488c-ad89-8fb13ed54722.yunxing.cyx@alibaba-inc.com> References: <552b24e6-6782-488c-ad89-8fb13ed54722.yunxing.cyx@alibaba-inc.com> Message-ID: <0aa986e0-6367-46c6-b657-e259d30eca4e.yunxing.cyx@alibaba-inc.com> The Linux community has an aio enhance (io_uring: https://kernel.dk/io_uring.pdf) to replace Linux Native AIO. does jdk have a plan to add this backend and export an asynchronous IO interface to enable high performance File based IO ? Thansk :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Thu Dec 12 16:48:07 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 12 Dec 2019 11:48:07 -0500 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> Message-ID: <3F84F80B-61A1-4AEB-86D8-2DA3F2667FE5@oracle.com> Attached is the updated patch for addressing the permissions based on feedback from Alan: http://cr.openjdk.java.net/~lancea/8229888/webrev.02/index.html Best Lance > On Dec 9, 2019, at 1:28 PM, Lance Andersen wrote: > > Here is a revised patch: http://cr.openjdk.java.net/~lancea/8229888/webrev.01/index.html . > > > I spent some time trying leverage createTempFileinSameDirectoryAs but it was getting messy as this method is also used when creating temp files in a zip to zip copy. I might try to revisit this later but the above seemed more straight forwarded > > Best > Lance > >> On Dec 3, 2019, at 6:45 PM, Lance Andersen > wrote: >> >> Thank you for the comments Alan. >> >>> On Dec 3, 2019, at 4:04 PM, Alan Bateman > wrote: >>> >>> On 03/12/2019 00:59, Lance Andersen wrote: >>>> HI all, >>>> >>>> Please review the proposed fix for an issue with Zip FS where the permissions set on the Zip file are not retained when the Zip file is updated. >>>> >>>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8229888/webrev.00/index.html >>>> >>> Testing the underlying FileStore to see if supports "posix" may be problematic or costly here as it requires finding the mount entry file the underlying file store. You should find that it is much more efficient to just call getPosixFileAttributes >> Did you mean: Files.getPosixFilePermissions >> >>> and catch UOE (using exceptions for control flow is not nice of course but you will avoid a lot of issues). In passing, I should mention that the non-stringy way to to check if POSIX file permissions are support is to invoke on supportsFileAttributeView(PosixFIleAttributeView.class). >> >> >> Would the following be more efficient than catching the IOE as I saw it used in TempFileHelper: >> >> -------- >> boolean isPosix = FileSystems.getDefault().supportedFileAttributeViews().contains("posix"); >> -------- >> >>> >>> One other approach to look at is just letting Files.move copy the file attributes. It will copy file permissions and attempt to copy all other attributes (it only fails if it can't copy the basic file attributes to the file in its new location). Another point is that the Files.newOutputStream to create the file next to the original zip file can be created with initial file attributes. Combined with Files.move it means there is another way to do this. I only mention is because I assume there will be follow on issues to fix up other file attributes of the zip file that are lost when it is re-created. >> >> If I am understanding this suggestion, it would be to modify the call to Files.createTempFile in the method createTempFileinSameDirectoryAs to pass the original zip file permissions as an file attribute ? >> >> Best >> Lance >>> >>> -Alan >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From Alan.Bateman at oracle.com Fri Dec 13 17:49:30 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Dec 2019 17:49:30 +0000 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: <3F84F80B-61A1-4AEB-86D8-2DA3F2667FE5@oracle.com> References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> <3F84F80B-61A1-4AEB-86D8-2DA3F2667FE5@oracle.com> Message-ID: <5ffe33dd-8999-ee72-f64a-784f0836ba2a@oracle.com> On 12/12/2019 16:48, Lance Andersen wrote: > Attached is the updated patch for addressing the permissions based on > feedback from Alan: > http://cr.openjdk.java.net/~lancea/8229888/webrev.02/index.html Thanks for this update, the implementation changes looks right. I skimmed through the test and it looks okay but would be good if Christoph or someone else has cycles to do a more detailed review there. -Alan From christoph.langer at sap.com Tue Dec 17 08:24:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Dec 2019 08:24:15 +0000 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: <3F84F80B-61A1-4AEB-86D8-2DA3F2667FE5@oracle.com> References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> <3F84F80B-61A1-4AEB-86D8-2DA3F2667FE5@oracle.com> Message-ID: Hi Lance, I checked your patch. I think it is correct, I only have a few style nits which you may or may not address (no need for further webrev, though): src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java: Line 1793: Maybe the comment should rather be: // Set the POSIX permissions of the original Zip File if available Line 1804: The path to the file (need not necessarily be a zip file) Line 1806: I would indent the comment to the same column as "The" in the row above - makes it more readable. Also, there is a space too much between "the" and "POSIX" Line 1808: Indention as above Line 1811: Remove Line 1816: Insert blank between if and ( test/jdk/jdk/nio/zipfs/ZipFSPermissionsTest.java: Line 68: Remove Line 85: Remove Method teardown, line 97: I think this method is not needed. zipFile is already deleted before each test in method "before()" and in the end you clean up via "suiteCleanUp()". So maybe tearDown can/should be removed? Line 113: Maybe you should move "Zip file" to the line before while keeping this line as a blank line Line 115: Same as with 113 Line 120: Space between if and ( Line 181: Same as in 120 Method getPosixAttributes, line 199: I think you should remove the try/catch UnsupportedOperationException. If the test is run on a non-posix fs, the whole test is skipped in setup() anyways. Cheers Christoph From: nio-dev On Behalf Of Lance Andersen Sent: Donnerstag, 12. Dezember 2019 17:48 Cc: nio-dev Subject: Re: RFR 8229888: Zip FS does not retain permissions when updating a Zip file Attached is the updated patch for addressing the permissions based on feedback from Alan: http://cr.openjdk.java.net/~lancea/8229888/webrev.02/index.html Best Lance On Dec 9, 2019, at 1:28 PM, Lance Andersen > wrote: Here is a revised patch: http://cr.openjdk.java.net/~lancea/8229888/webrev.01/index.html. I spent some time trying leverage createTempFileinSameDirectoryAs but it was getting messy as this method is also used when creating temp files in a zip to zip copy. I might try to revisit this later but the above seemed more straight forwarded Best Lance On Dec 3, 2019, at 6:45 PM, Lance Andersen > wrote: Thank you for the comments Alan. On Dec 3, 2019, at 4:04 PM, Alan Bateman > wrote: On 03/12/2019 00:59, Lance Andersen wrote: HI all, Please review the proposed fix for an issue with Zip FS where the permissions set on the Zip file are not retained when the Zip file is updated. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8229888/webrev.00/index.html Testing the underlying FileStore to see if supports "posix" may be problematic or costly here as it requires finding the mount entry file the underlying file store. You should find that it is much more efficient to just call getPosixFileAttributes Did you mean: Files.getPosixFilePermissions and catch UOE (using exceptions for control flow is not nice of course but you will avoid a lot of issues). In passing, I should mention that the non-stringy way to to check if POSIX file permissions are support is to invoke on supportsFileAttributeView(PosixFIleAttributeView.class). Would the following be more efficient than catching the IOE as I saw it used in TempFileHelper: -------- boolean isPosix = FileSystems.getDefault().supportedFileAttributeViews().contains("posix"); -------- One other approach to look at is just letting Files.move copy the file attributes. It will copy file permissions and attempt to copy all other attributes (it only fails if it can't copy the basic file attributes to the file in its new location). Another point is that the Files.newOutputStream to create the file next to the original zip file can be created with initial file attributes. Combined with Files.move it means there is another way to do this. I only mention is because I assume there will be follow on issues to fix up other file attributes of the zip file that are lost when it is re-created. If I am understanding this suggestion, it would be to modify the call to Files.createTempFile in the method createTempFileinSameDirectoryAs to pass the original zip file permissions as an file attribute ? Best Lance -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com [cid:image001.gif at 01D5B4B9.AC6B4BC0] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From fweimer at redhat.com Tue Dec 17 11:58:45 2019 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Dec 2019 12:58:45 +0100 Subject: [RFC] 4950302: (fs spec) Random write produces different results on Linux vs Windows from same .class In-Reply-To: (David Lloyd's message of "Wed, 20 Nov 2019 07:09:28 -0600") References: Message-ID: <87fthjcgei.fsf@oldenburg2.str.redhat.com> * David Lloyd: > If toggling the mode is unacceptable, an > also-not-so-great-but-should-work alternative workaround would be to > open `/proc/self/fd/` and write to that (basically this works > more or less like dup() but doesn't share file offset and flags). > Then you're not toggling file modes - though it will of course fail if > you run out of file descriptors. And you cannot close the alternate descriptor because doing so would release advisory locks on the first descriptor (as required by POSIX). Thanks, Florian From patrick.concannon at oracle.com Tue Dec 17 14:35:49 2019 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Tue, 17 Dec 2019 14:35:49 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException Message-ID: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> Hi, Could someone please review my fix and CSR for issue JDK-8235783 'DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException'? DatagramChannel's connect and disconnect methods throw an IOException while DatagramSocket's corresponding methods do not. The proposed fix changes the specification of DatagramSocket::connect and DatagramSocket::disconnect to document that an implementation may throw UncheckedIOException. In addition, and similar to what was done for DatagramChannel, an @apiNote is added to DatagramSocket::disconnect to recommend closing the socket if an IO exception occurs, as the underlying socket might have been left in an inconsistent and unspecified state bug: https://bugs.openjdk.java.net/browse/JDK-8235783 CSR: https://bugs.openjdk.java.net/browse/JDK-8236076 webrev: http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.00/ Kind regards, Patrick From brian.burkhalter at oracle.com Wed Dec 18 01:12:36 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Dec 2019 17:12:36 -0800 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: References: <04a647da-67c8-95db-8267-92a24445cb53@oracle.com> <7CB91114-CA75-497D-9BA9-5ED9D6D516EF@oracle.com> <3F84F80B-61A1-4AEB-86D8-2DA3F2667FE5@oracle.com> Message-ID: <5291C76E-5DCC-425F-8E34-6E7992D30EEF@oracle.com> Hi Lance, No further comments beyond what Christoph wrote aside from noticing that the GROUP_EXECUTE permission is not tested so perhaps you might want to add it somewhere in the DataProvider in the test. Brian > On Dec 17, 2019, at 12:24 AM, Langer, Christoph wrote: > > I checked your patch. I think it is correct, I only have a few style nits which you may or may not address (no need for further webrev, though): > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java: > Line 1793: Maybe the comment should rather be: // Set the POSIX permissions of the original Zip File if available > Line 1804: The path to the file (need not necessarily be a zip file) > Line 1806: I would indent the comment to the same column as ?The? in the row above ? makes it more readable. Also, there is a space too much between ?the? and ?POSIX? > Line 1808: Indention as above > Line 1811: Remove > Line 1816: Insert blank between if and ( > > test/jdk/jdk/nio/zipfs/ZipFSPermissionsTest.java: > Line 68: Remove > Line 85: Remove > Method teardown, line 97: I think this method is not needed. zipFile is already deleted before each test in method ?before()? and in the end you clean up via ?suiteCleanUp()?. So maybe tearDown can/should be removed? > Line 113: Maybe you should move ?Zip file? to the line before while keeping this line as a blank line > Line 115: Same as with 113 > Line 120: Space between if and ( > Line 181: Same as in 120 > Method getPosixAttributes, line 199: I think you should remove the try/catch UnsupportedOperationException. If the test is run on a non-posix fs, the whole test is skipped in setup() anyways. > > Cheers > Christoph > > > From: nio-dev > On Behalf Of Lance Andersen > Sent: Donnerstag, 12. Dezember 2019 17:48 > Cc: nio-dev > > Subject: Re: RFR 8229888: Zip FS does not retain permissions when updating a Zip file > > Attached is the updated patch for addressing the permissions based on feedback from Alan: http://cr.openjdk.java.net/~lancea/8229888/webrev.02/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lance.Andersen at oracle.com Wed Dec 18 01:22:57 2019 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Tue, 17 Dec 2019 20:22:57 -0500 Subject: RFR 8229888: Zip FS does not retain permissions when updating a Zip file In-Reply-To: <5291C76E-5DCC-425F-8E34-6E7992D30EEF@oracle.com> References: <5291C76E-5DCC-425F-8E34-6E7992D30EEF@oracle.com> Message-ID: <7119DB83-F38F-4D1E-80A3-291CE7EAEC78@oracle.com> Hi Brian Thank you for the review I can add an entry to the data provider as you suggest before I push the patch Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPhone > On Dec 17, 2019, at 8:12 PM, Brian Burkhalter wrote: > > ?Hi Lance, > > No further comments beyond what Christoph wrote aside from noticing that the GROUP_EXECUTE permission is not tested so perhaps you might want to add it somewhere in the DataProvider in the test. > > Brian > >> On Dec 17, 2019, at 12:24 AM, Langer, Christoph wrote: >> >> I checked your patch. I think it is correct, I only have a few style nits which you may or may not address (no need for further webrev, though): >> >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java: >> Line 1793: Maybe the comment should rather be: // Set the POSIX permissions of the original Zip File if available >> Line 1804: The path to the file (need not necessarily be a zip file) >> Line 1806: I would indent the comment to the same column as ?The? in the row above ? makes it more readable. Also, there is a space too much between ?the? and ?POSIX? >> Line 1808: Indention as above >> Line 1811: Remove >> Line 1816: Insert blank between if and ( >> >> test/jdk/jdk/nio/zipfs/ZipFSPermissionsTest.java: >> Line 68: Remove >> Line 85: Remove >> Method teardown, line 97: I think this method is not needed. zipFile is already deleted before each test in method ?before()? and in the end you clean up via ?suiteCleanUp()?. So maybe tearDown can/should be removed? >> Line 113: Maybe you should move ?Zip file? to the line before while keeping this line as a blank line >> Line 115: Same as with 113 >> Line 120: Space between if and ( >> Line 181: Same as in 120 >> Method getPosixAttributes, line 199: I think you should remove the try/catch UnsupportedOperationException. If the test is run on a non-posix fs, the whole test is skipped in setup() anyways. >> >> Cheers >> Christoph >> >> >> From: nio-dev On Behalf Of Lance Andersen >> Sent: Donnerstag, 12. Dezember 2019 17:48 >> Cc: nio-dev >> Subject: Re: RFR 8229888: Zip FS does not retain permissions when updating a Zip file >> >> Attached is the updated patch for addressing the permissions based on feedback from Alan: http://cr.openjdk.java.net/~lancea/8229888/webrev.02/index.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 18 10:01:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Dec 2019 10:01:40 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> Message-ID: On 17/12/2019 14:35, Patrick Concannon wrote: > Hi, > > Could someone please review my fix and CSR for issue JDK-8235783 > 'DatagramSocket::disconnect should allow an implementation to throw > UncheckedIOException'? > > DatagramChannel's connect and disconnect methods throw an IOException > while DatagramSocket's corresponding methods do not. The proposed fix > changes the specification of DatagramSocket::connect and > DatagramSocket::disconnect to document that an implementation may > throw UncheckedIOException. > In addition, and similar to what was done for DatagramChannel, an > @apiNote is added to DatagramSocket::disconnect to recommend closing > the socket if an IO exception occurs, as the underlying socket might > have been left in an inconsistent and unspecified state > > bug: https://bugs.openjdk.java.net/browse/JDK-8235783 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8236076 > webrev: http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.00/ A couple of things in this area to think about: 1. DatagramSocket connect does nothing when the socket is closed and we might want specify that some day to avoid the reader wondering if UncheckedIOException will be thrown when the socket is closed. 2. DatagramSocket connect will bind the socket is not already bound and we might want to specify that some day. The bind could fail so that is a potential reason for throwing UncheckedIOException (or SecurityException is unlikely scenarios). 3. DatagramSocket.connect silently falls back to emulation when the underlying connect fails. I think this is a bug as it hides a problem like trying to connect to a non-routable addresses, but may have been done this way to avoid incomplete DatagramSocketImpl implementations. I guess my point here is that UncheckedIOException will never be thrown, which might be okay if the primary motive is to prepare DatagramSocket for the new implementation. 4. If you are open to word smithing on the @throws descriptions then I think dropping "by an implementation" will help the wording a bit. Also I think the description should make it clear that the exception cause is the IOException with the underlying I/O error. -Alan. From daniel.fuchs at oracle.com Wed Dec 18 10:55:05 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Dec 2019 11:55:05 +0100 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> Message-ID: <9c25ed30-2096-9953-8ab2-86c2001504ad@oracle.com> Hi Alan, On 18/12/2019 11:01, Alan Bateman wrote: > I guess my point here is that UncheckedIOException will never be thrown, > which might be okay if the primary motive is to prepare DatagramSocket > for the new implementation. We already have two implementations of DatagramSocket: one is the plain DatagramSocket, the other is the DatagramSocket adapter created by DatagramChannel::socket. Even without preparing for DatagramSocket reimplementation this is a step forward in homogenizing these two implementations in the spec. > DatagramSocket connect does nothing when the socket is closed and we might want specify that some day to avoid the reader wondering if UncheckedIOException will be thrown when the socket is closed. Oh - I see DatagramChannel::socket adapter also behaves like this and explicitly ignores the ClosedChannelException. Is there any reason for letting connect go through if the socket is closed? I mean - should we change the spec/behavior of DatagramSocket (and the adapter) to throw in that case? best regards, -- daniel From Alan.Bateman at oracle.com Wed Dec 18 11:09:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Dec 2019 11:09:03 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: <9c25ed30-2096-9953-8ab2-86c2001504ad@oracle.com> References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> <9c25ed30-2096-9953-8ab2-86c2001504ad@oracle.com> Message-ID: <671e92cf-f7b2-e80f-7bd4-24a6fea4094b@oracle.com> On 18/12/2019 10:55, Daniel Fuchs wrote: > We already have two implementations of DatagramSocket: one is the plain > DatagramSocket, the other is the DatagramSocket adapter created by > DatagramChannel::socket. > > Even without preparing for DatagramSocket reimplementation this > is a step forward in homogenizing these two implementations in > the spec. > > Oh - I see DatagramChannel::socket adapter also behaves like this > and explicitly ignores the ClosedChannelException. > > Is there any reason for letting connect go through if the socket > is closed? I mean - should we change the spec/behavior of > DatagramSocket (and the adapter) to throw in that case? Changing DatagramSocket connect to throw an exception when the socket is closed would be an incompatible change so I think this is a case where the spec will just need to align with long standing behavior. The disconnect method already specifies that it is a no-op when the socket is closed so at least they will be consistent. BTW: I think socket adaptor behavior should take a back seat in any spec discussions as its raison d'etre was to support binding and socket options. It does have to do a few ugly things in places (like catch ClosedChannelException) but this is only because it emulate legacy DatagramSocket behavior (both specified and unspecified). -Alan. From chris.hegarty at oracle.com Wed Dec 18 15:06:31 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 18 Dec 2019 15:06:31 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: <671e92cf-f7b2-e80f-7bd4-24a6fea4094b@oracle.com> References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> <9c25ed30-2096-9953-8ab2-86c2001504ad@oracle.com> <671e92cf-f7b2-e80f-7bd4-24a6fea4094b@oracle.com> Message-ID: <293788FA-1638-4D7C-B0FF-2A6C14349965@oracle.com> > On 18 Dec 2019, at 11:09, Alan Bateman wrote: > > On 18/12/2019 10:55, Daniel Fuchs wrote: >> We already have two implementations of DatagramSocket: one is the plain >> DatagramSocket, the other is the DatagramSocket adapter created by >> DatagramChannel::socket. >> >> Even without preparing for DatagramSocket reimplementation this >> is a step forward in homogenizing these two implementations in >> the spec. Yeah, and we have done similar in the past. >> Oh - I see DatagramChannel::socket adapter also behaves like this >> and explicitly ignores the ClosedChannelException. >> >> Is there any reason for letting connect go through if the socket >> is closed? I mean - should we change the spec/behavior of >> DatagramSocket (and the adapter) to throw in that case? > Changing DatagramSocket connect to throw an exception when the socket is closed would be an incompatible True, such a change, if it were to be proposed, would require a CSR. > change so I think this is a case where the spec will just need to align with long standing behavior. Not withstanding the various different post-close behaviour of the methods of DatagramSocket ( throw IOException, silently ignore, return a default value, return last known value ), I think that it would be best to clarify the specification with the existing, long standing, behaviour; "Invoking this method on a closed socket has *effectively* no effect." - or something like that. It would be good to clarify that now, as part of this change, since it?s an obvious question that arises now that UncheckedIOException is being added. -Chris. From daniel.fuchs at oracle.com Wed Dec 18 15:10:30 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Dec 2019 16:10:30 +0100 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: <293788FA-1638-4D7C-B0FF-2A6C14349965@oracle.com> References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> <9c25ed30-2096-9953-8ab2-86c2001504ad@oracle.com> <671e92cf-f7b2-e80f-7bd4-24a6fea4094b@oracle.com> <293788FA-1638-4D7C-B0FF-2A6C14349965@oracle.com> Message-ID: On 18/12/2019 16:06, Chris Hegarty wrote: > Not withstanding the various different post-close behaviour of the > methods of DatagramSocket ( throw IOException, silently ignore, return a > default value, return last known value ), I think that it would be best > to clarify the specification with the existing, long standing, > behaviour; "Invoking this method on a closed socket has*effectively* no > effect." - or something like that. > > It would be good to clarify that now, as part of this change, since it?s > an obvious question that arises now that UncheckedIOException is being > added. Agreed. -- daniel From Alan.Bateman at oracle.com Wed Dec 18 16:47:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Dec 2019 16:47:33 +0000 Subject: 8236184: (dc) IP_MULTICAST_* and IP_TOS socket options not effective Message-ID: <81c583b0-9edc-7b35-b732-6ea60b5c6568@oracle.com> This is another update to the DatagramChannel implementation so that it can be used by the upcoming re-implementation of DatagramSocket and MulticastSocket. DatagramChannel has good multicast support but some of the IP_ socket options are only are effective for IPv6 datagrams when the channel's socket is IPv6, e.g. IP_MUILTICAST_IF sets the outgoing multicast interface for IPv6 multicast datagrams but not IPv4 multicast datagrams. The javadoc is clear that many aspects of multicasting are platform dependent and all of the IP_ socket options are clear that it is platform specific as to whether they apply to IPv4 datagrams when the socket is IPv6. So not a concern for DatagramChannel as the protocol family is specified as creation time. However it is a concern for code using the existing MulticastSocket API as the protocol family cannot be specified. The patch proposed here updates DatagramChannel's setOption implementation to set both the IPv4 and IPv6 sockets on platforms that support this. For example, setOption(IP_MULTICAST_TTL, 8) will attempt to set both IP_TOS and IPV6_TCLASS when the socket is IPv6 on platforms that allow IP_TOS to set the ToS field of IPv4 datagrams sent with the socket. Legacy networking has been doing the same on Linux for many releases. The change does the same on Windows, something legacy networking doesn't need to do because MulticastSocket uses two sockets on Windows. The webrev with the changes is here: ? http://cr.openjdk.java.net/~alanb/8236184/webrev/ Testing these changes is difficult and requires using tcpdump/equivalent to look at the network. However we can test IP_MULTICAST_LOOP so I've added a test for that. -Alan From daniel.fuchs at oracle.com Wed Dec 18 17:10:58 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Dec 2019 18:10:58 +0100 Subject: 8236184: (dc) IP_MULTICAST_* and IP_TOS socket options not effective In-Reply-To: <81c583b0-9edc-7b35-b732-6ea60b5c6568@oracle.com> References: <81c583b0-9edc-7b35-b732-6ea60b5c6568@oracle.com> Message-ID: <773ca8e4-1580-e021-3080-874f7f027f40@oracle.com> Hi Alan, DatagramChannelImpl: 382 // remaining options don't need any special handling 383 Net.setSocketOption(fd, family, name, value); 384 if (needToSetIPv4Option) { 385 try { 386 Net.setSocketOption(fd, StandardProtocolFamily.INET, name, value); 387 } catch (IOException ignore) { } 388 } If family == StandardProtocolFamily.INET && needToSetIPv4Option won't that set the option twice? If this is impossible - maybe an assert could make it explicit: assert family != StandardProtocolFamily.INET || !needToSetIPv4Option Otherwise looks reasonable to me. Does the new test pass reliably on macOS? We already have some multicast tests in the ProblemList.txt for that platform. best regards, -- daniel On 18/12/2019 17:47, Alan Bateman wrote: > > This is another update to the DatagramChannel implementation so that it > can be used by the upcoming re-implementation of DatagramSocket and > MulticastSocket. > > DatagramChannel has good multicast support but some of the IP_ socket > options are only are effective for IPv6 datagrams when the channel's > socket is IPv6, e.g. IP_MUILTICAST_IF sets the outgoing multicast > interface for IPv6 multicast datagrams but not IPv4 multicast datagrams. > The javadoc is clear that many aspects of multicasting are platform > dependent and all of the IP_ socket options are clear that it is > platform specific as to whether they apply to IPv4 datagrams when the > socket is IPv6. So not a concern for DatagramChannel as the protocol > family is specified as creation time. However it is a concern for code > using the existing MulticastSocket API as the protocol family cannot be > specified. > > The patch proposed here updates DatagramChannel's setOption > implementation to set both the IPv4 and IPv6 sockets on platforms that > support this. For example, setOption(IP_MULTICAST_TTL, 8) will attempt > to set both IP_TOS and IPV6_TCLASS when the socket is IPv6 on platforms > that allow IP_TOS to set the ToS field of IPv4 datagrams sent with the > socket. Legacy networking has been doing the same on Linux for many > releases. The change does the same on Windows, something legacy > networking doesn't need to do because MulticastSocket uses two sockets > on Windows. > > The webrev with the changes is here: > ? http://cr.openjdk.java.net/~alanb/8236184/webrev/ > > Testing these changes is difficult and requires using tcpdump/equivalent > to look at the network. However we can test IP_MULTICAST_LOOP so I've > added a test for that. > > > -Alan From Alan.Bateman at oracle.com Wed Dec 18 17:59:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Dec 2019 17:59:26 +0000 Subject: 8236184: (dc) IP_MULTICAST_* and IP_TOS socket options not effective In-Reply-To: <773ca8e4-1580-e021-3080-874f7f027f40@oracle.com> References: <81c583b0-9edc-7b35-b732-6ea60b5c6568@oracle.com> <773ca8e4-1580-e021-3080-874f7f027f40@oracle.com> Message-ID: <6aa58ffb-567d-1ac6-ed80-612dd19d0862@oracle.com> On 18/12/2019 17:10, Daniel Fuchs wrote: > Hi Alan, > > DatagramChannelImpl: > > ?382???????????? // remaining options don't need any special handling > ?383???????????? Net.setSocketOption(fd, family, name, value); > ?384???????????? if (needToSetIPv4Option) { > ?385???????????????? try { > ?386???????????????????? Net.setSocketOption(fd, > StandardProtocolFamily.INET, name, value); > ?387???????????????? } catch (IOException ignore) { } > ?388???????????? } > > If family == StandardProtocolFamily.INET && needToSetIPv4Option > won't that set the option twice? > > If this is impossible - maybe an assert could make it explicit: > ?? assert family != StandardProtocolFamily.INET || !needToSetIPv4Option Thanks, and well spotted! This scenario will arise on Windows if the channel's socket is IPv6 and it is bound IPv4 local address. It doesn't arise on other platforms. So in this Windows scenario it would indeed set the IPv4 socket option twice. Harmless but L384 should be: if (family != StandardProtocolFamily.INET && needToSetIPv4Option) { > > > Otherwise looks reasonable to me. > Does the new test pass reliably on macOS? We already have some > multicast tests in the ProblemList.txt for that platform. The @requires limits the platforms that it runs on so macOS is skipped because IPv4 socket options are not effective on IPv6 sockets there. There are several issues open in JBS on this, the workaround is -Djava.net.preferIPv4Stack=true on macOS. MulticastSocket has the same issue of course. -Alan From daniel.fuchs at oracle.com Wed Dec 18 18:11:42 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Dec 2019 19:11:42 +0100 Subject: 8236184: (dc) IP_MULTICAST_* and IP_TOS socket options not effective In-Reply-To: <6aa58ffb-567d-1ac6-ed80-612dd19d0862@oracle.com> References: <81c583b0-9edc-7b35-b732-6ea60b5c6568@oracle.com> <773ca8e4-1580-e021-3080-874f7f027f40@oracle.com> <6aa58ffb-567d-1ac6-ed80-612dd19d0862@oracle.com> Message-ID: <4134590b-2a55-a63b-2f2b-86583aaa006d@oracle.com> On 18/12/2019 18:59, Alan Bateman wrote: > So in this Windows scenario it would indeed > set the IPv4 socket option twice. Harmless but L384 should be: > > if (family != StandardProtocolFamily.INET && needToSetIPv4Option) { > +1 > The @requires limits the platforms that it runs on so macOS is skipped > because IPv4 socket options are not effective on IPv6 sockets there. > There are several issues open in JBS on this, the workaround is > -Djava.net.preferIPv4Stack=true on macOS. MulticastSocket has the same > issue of course. Ah! I missed the @requires. Looks good. -- daniel > > -Alan From Alan.Bateman at oracle.com Thu Dec 19 15:25:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Dec 2019 15:25:36 +0000 Subject: 8236246: SelectorProvider support for creating a DatagramChannel that is not interruptible Message-ID: <70ee4d42-3cb5-cd32-6ef1-f13921ac3ea5@oracle.com> This is an update to the SelectorProvider implementation with two related parts to it: 1. The upcoming replacement of the DatagramSocket and MulticastSocket implementations needs a socket adaptor that is not interruptible. It also needs to be able to create it with built-in selector provider. This part of the changes makes this easy with DefaultSelectorProvider.get().openUninterruptibleDatagramChannel(). The main difference between an interruptible and uninterruptible DatagramChannel is that the hooks for Thread.interrupt aren't setup around blocking operations, instead the uninterruptible case just needs to check for async close at the end of blocking operations. 2. The second part is that SelectorProvider is specified to locate the default provider when its "provider" method is first called. The current implementation uses a lock to allow that initialization but it means that the creation of all channels with the static factory methods (the common case) ends up being synchronized. Moving the initialization of the default provider to a holder class allows this lock to be removed. The webrev with the changes is here. I've added a test to exercise the (internal) openUninterruptibleDatagramChannel. http://cr.openjdk.java.net/~alanb/8236246/webrev/ SAP folks - sun.nio.ch.DefaultSelectorProvider is changed but I have no way to test the AIX change. I assume your testing will catch any issues there. -Alan From chris.hegarty at oracle.com Thu Dec 19 16:58:26 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Dec 2019 16:58:26 +0000 Subject: 8236246: SelectorProvider support for creating a DatagramChannel that is not interruptible In-Reply-To: <70ee4d42-3cb5-cd32-6ef1-f13921ac3ea5@oracle.com> References: <70ee4d42-3cb5-cd32-6ef1-f13921ac3ea5@oracle.com> Message-ID: <39D4F369-579E-433E-B340-15E39276349B@oracle.com> Alan, > On 19 Dec 2019, at 15:25, Alan Bateman wrote: > > This is an update to the SelectorProvider implementation with two related parts to it: > > 1. The upcoming replacement of the DatagramSocket and MulticastSocket implementations needs a socket adaptor that is not interruptible. It also needs to be able to create it with built-in selector provider. This part of the changes makes this easy with DefaultSelectorProvider.get().openUninterruptibleDatagramChannel(). The main difference between an interruptible and uninterruptible DatagramChannel is that the hooks for Thread.interrupt aren't setup around blocking operations, instead the uninterruptible case just needs to check for async close at the end of blocking operations. > > 2. The second part is that SelectorProvider is specified to locate the default provider when its "provider" method is first called. The current implementation uses a lock to allow that initialization but it means that the creation of all channels with the static factory methods (the common case) ends up being synchronized. Moving the initialization of the default provider to a holder class allows this lock to be removed. > > The webrev with the changes is here. I've added a test to exercise the (internal) openUninterruptibleDatagramChannel. > > http://cr.openjdk.java.net/~alanb/8236246/webrev/ This seems fine. There is a lot of duplication between the platform-specific DefaultSelectorProvider code. Can this be consolidated? I checked the DatagramChannelImpl changes against what is in the sandbox branch for the upcoming proposal to replacement of DS & MS [1], and the code in this webrev seems to logically equivalent. -Chris. [1] http://hg.openjdk.java.net/jdk/sandbox/rev/8c724fbaeb99 From chris.hegarty at oracle.com Thu Dec 19 17:27:59 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Dec 2019 17:27:59 +0000 Subject: 8236246: SelectorProvider support for creating a DatagramChannel that is not interruptible In-Reply-To: <39D4F369-579E-433E-B340-15E39276349B@oracle.com> References: <70ee4d42-3cb5-cd32-6ef1-f13921ac3ea5@oracle.com> <39D4F369-579E-433E-B340-15E39276349B@oracle.com> Message-ID: <430F5A22-0444-42E4-B81F-154AE950F624@oracle.com> > On 19 Dec 2019, at 16:58, Chris Hegarty wrote: > >> ... >> http://cr.openjdk.java.net/~alanb/8236246/webrev/ > > > This seems fine. > > There is a lot of duplication between the platform-specific > DefaultSelectorProvider code. Can this be consolidated? An additional minor thought, maybe SelectorProviderImpl can add the @Override annotation to the overridden methods, from SelectorProvider, ( making it blatantly obvious that this new method is not part of SP ). -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Dec 19 18:02:11 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Dec 2019 18:02:11 +0000 Subject: 8236246: SelectorProvider support for creating a DatagramChannel that is not interruptible In-Reply-To: <39D4F369-579E-433E-B340-15E39276349B@oracle.com> References: <70ee4d42-3cb5-cd32-6ef1-f13921ac3ea5@oracle.com> <39D4F369-579E-433E-B340-15E39276349B@oracle.com> Message-ID: <9270508c-bd0a-1da0-109e-c1e6dae8837e@oracle.com> On 19/12/2019 16:58, Chris Hegarty wrote: > : > This seems fine. > > There is a lot of duplication between the platform-specific > DefaultSelectorProvider code. Can this be consolidated? > I agree. It used to be one class that used Class.forName to load the platform specific provider. At another time there was very platform specific selection going on in some of the implementations, e.g. Linux implementation would return the poll or epoll SelectorProvider based on the kernel version. They have been simplified in recent releases to just return one implementation without needing to do anything else to choose. So yes, something for a follow-on issue I think. -Alan From Alan.Bateman at oracle.com Thu Dec 19 18:03:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Dec 2019 18:03:10 +0000 Subject: 8236246: SelectorProvider support for creating a DatagramChannel that is not interruptible In-Reply-To: <430F5A22-0444-42E4-B81F-154AE950F624@oracle.com> References: <70ee4d42-3cb5-cd32-6ef1-f13921ac3ea5@oracle.com> <39D4F369-579E-433E-B340-15E39276349B@oracle.com> <430F5A22-0444-42E4-B81F-154AE950F624@oracle.com> Message-ID: <1e8ca300-6ea3-a985-0730-e4774682ccaa@oracle.com> On 19/12/2019 17:27, Chris Hegarty wrote: > An additional minor thought, maybe SelectorProviderImpl can add the > @Override annotation to the overridden methods, from SelectorProvider, > ( making it blatantly obvious that this new method is not part of SP ). > Okay, will do that before pushing this change. -Alan From daniel.fuchs at oracle.com Fri Dec 20 11:26:33 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 20 Dec 2019 12:26:33 +0100 Subject: (teststabilization) RFR: 8208281: java/nio/channels/AsynchronousSocketChannel/Basic.java timed out Message-ID: Hi, Please find below a trivial fix that might solve the test issue for: 8208281: java/nio/channels/AsynchronousSocketChannel/Basic.java timed out https://bugs.openjdk.java.net/browse/JDK-8208281 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8208281/webrev.00/ The test creates a ServerSocket, then connect a client to it, then close the client, accept the connection, and close the accepted connection. The test has been observed infrequently blocking in the accept() method on Windows platform. My suspicion is that maybe closing the client socket before accepting the connection on the server side might have enabled the kernel to consider that the connection had never happened, and it's now waiting for a *new* connection, which never comes. This fix proposes to simply accept the socket before closing the client. I haven't been able to reproduce the issue, so I have no proof that my suspicion is right. However, the fix is trivial, eliminates that possible cause for the failure, and doesn't change what the test is testing in any way, so I believe it's worth doing it. best regards, -- daniel From Alan.Bateman at oracle.com Fri Dec 20 11:30:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Dec 2019 11:30:23 +0000 Subject: (teststabilization) RFR: 8208281: java/nio/channels/AsynchronousSocketChannel/Basic.java timed out In-Reply-To: References: Message-ID: On 20/12/2019 11:26, Daniel Fuchs wrote: > : > > This fix proposes to simply accept the socket before closing > the client. I haven't been able to reproduce the issue, so I > have no proof that my suspicion is right. > > However, the fix is trivial, eliminates that possible cause > for the failure, and doesn't change what the test is testing > in any way, so I believe it's worth doing it. I think this change is benign but I think it removes one line of investigation (my guess is that the issue is somewhere else). Can you use "peer" instead of "ch" to keep it consistent with the existing usage? -Alan. From daniel.fuchs at oracle.com Fri Dec 20 11:43:01 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 20 Dec 2019 12:43:01 +0100 Subject: (teststabilization) RFR: 8208281: java/nio/channels/AsynchronousSocketChannel/Basic.java timed out In-Reply-To: References: Message-ID: On 20/12/2019 12:30, Alan Bateman wrote: > I think this change is benign but I think it removes one line of > investigation (my guess is that the issue is somewhere else). Can you > use "peer" instead of "ch" to keep it consistent with the existing usage? Thanks Alan! Done: http://cr.openjdk.java.net/~dfuchs/webrev_8208281/webrev.01/ best regards, -- daniel From Alan.Bateman at oracle.com Fri Dec 20 12:26:14 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Dec 2019 12:26:14 +0000 Subject: (teststabilization) RFR: 8208281: java/nio/channels/AsynchronousSocketChannel/Basic.java timed out In-Reply-To: References: Message-ID: <73aa76e5-a83a-c7b6-d617-d424a945d0d8@oracle.com> On 20/12/2019 11:43, Daniel Fuchs wrote: > > Done: http://cr.openjdk.java.net/~dfuchs/webrev_8208281/webrev.01/ I assume L356 needs to change too as peer will already be declared. Otherwise looks fine, no need for another webrev. -Alan From daniel.fuchs at oracle.com Fri Dec 20 12:55:46 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 20 Dec 2019 13:55:46 +0100 Subject: (teststabilization) RFR: 8208281: java/nio/channels/AsynchronousSocketChannel/Basic.java timed out In-Reply-To: <73aa76e5-a83a-c7b6-d617-d424a945d0d8@oracle.com> References: <73aa76e5-a83a-c7b6-d617-d424a945d0d8@oracle.com> Message-ID: <05b4e736-4907-4ee3-d4db-986170663179@oracle.com> On 20/12/2019 13:26, Alan Bateman wrote: >> Done: http://cr.openjdk.java.net/~dfuchs/webrev_8208281/webrev.01/ > I assume L356 needs to change too as peer will already be declared. > Otherwise looks fine, no need for another webrev. Ah! Good catch. Done. Thanks Alan! -- daniel From Alan.Bateman at oracle.com Mon Dec 30 15:11:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Dec 2019 15:11:40 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? Message-ID: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> Christoph, or others maintaining the AIX port: Do you know if isSourceFilterSupported in libnio/ch/Net.c is still needed? It looks like it is only needed on AIX releases prior to 6.1. I don't know anything about AIX releases but the wikipedia pages suggest the release prior to 6.1 ended service updates in 2012. I'm wondering if this code can be removed. Thanks. -Alan. From goetz.lindenmaier at sap.com Mon Dec 30 15:42:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Dec 2019 15:42:42 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? In-Reply-To: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> References: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> Message-ID: Hi Alan, in jdk/jdk, this code can be removed. We only support AIX 7 ++ with jdk/jdk. Best regards, Goetz. > -----Original Message----- > From: nio-dev On Behalf Of Alan > Bateman > Sent: Montag, 30. Dezember 2019 16:12 > To: nio-dev at openjdk.java.net; Langer, Christoph > Subject: Is isSourceFilterSupported still needed on AIX builds? > > > Christoph, or others maintaining the AIX port: Do you know if > isSourceFilterSupported in libnio/ch/Net.c is still needed? It looks > like it is only needed on AIX releases prior to 6.1. I don't know > anything about AIX releases but the wikipedia pages suggest the release > prior to 6.1 ended service updates in 2012. I'm wondering if this code > can be removed. > > Thanks. > > -Alan. From christoph.langer at sap.com Mon Dec 30 15:56:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 15:56:44 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? In-Reply-To: References: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> Message-ID: +1 > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 30. Dezember 2019 16:43 > To: Alan Bateman ; nio-dev at openjdk.java.net; > Langer, Christoph > Subject: RE: Is isSourceFilterSupported still needed on AIX builds? > > Hi Alan, > > in jdk/jdk, this code can be removed. > We only support AIX 7 ++ with jdk/jdk. > > Best regards, > Goetz. > > > -----Original Message----- > > From: nio-dev On Behalf Of Alan > > Bateman > > Sent: Montag, 30. Dezember 2019 16:12 > > To: nio-dev at openjdk.java.net; Langer, Christoph > > > Subject: Is isSourceFilterSupported still needed on AIX builds? > > > > > > Christoph, or others maintaining the AIX port: Do you know if > > isSourceFilterSupported in libnio/ch/Net.c is still needed? It looks > > like it is only needed on AIX releases prior to 6.1. I don't know > > anything about AIX releases but the wikipedia pages suggest the release > > prior to 6.1 ended service updates in 2012. I'm wondering if this code > > can be removed. > > > > Thanks. > > > > -Alan. From Alan.Bateman at oracle.com Mon Dec 30 15:59:29 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Dec 2019 15:59:29 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? In-Reply-To: References: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> Message-ID: <8c8a61c5-5aab-9202-e285-f4b9258e9d16@oracle.com> On 30/12/2019 15:42, Lindenmaier, Goetz wrote: > Hi Alan, > > in jdk/jdk, this code can be removed. > We only support AIX 7 ++ with jdk/jdk. > Thanks. Can you also check if IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP are defined? These may be candidates to remove from Net.c too. -Alan From christoph.langer at sap.com Mon Dec 30 22:48:22 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 22:48:22 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? In-Reply-To: <8c8a61c5-5aab-9202-e285-f4b9258e9d16@oracle.com> References: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> <8c8a61c5-5aab-9202-e285-f4b9258e9d16@oracle.com> Message-ID: Hi Alan, I checked... Although AIX documentation only refers to IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP, as per: https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/apis/ssocko.htm we can find this in netinet/in.h in both, AIX 7.1 and AIX 7.2: #define IPV6_ADD_MEMBERSHIP IP_ADD_MEMBERSHIP #define IPV6_JOIN_GROUP IP_ADD_MEMBERSHIP #define IPV6_DROP_MEMBERSHIP IP_DROP_MEMBERSHIP #define IPV6_LEAVE_GROUP IP_DROP_MEMBERSHIP So, both symbols are defined and to me it seems fine to drop their (conditional) definition from Net.c Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Montag, 30. Dezember 2019 16:59 > To: Lindenmaier, Goetz ; nio- > dev at openjdk.java.net; Langer, Christoph > Subject: Re: Is isSourceFilterSupported still needed on AIX builds? > > On 30/12/2019 15:42, Lindenmaier, Goetz wrote: > > Hi Alan, > > > > in jdk/jdk, this code can be removed. > > We only support AIX 7 ++ with jdk/jdk. > > > Thanks. Can you also check if IPV6_ADD_MEMBERSHIP and > IPV6_DROP_MEMBERSHIP are defined? These may be candidates to remove > from > Net.c too. > > -Alan From xu.y.yin at oracle.com Tue Dec 31 05:18:03 2019 From: xu.y.yin at oracle.com (Chris Yin) Date: Tue, 31 Dec 2019 13:18:03 +0800 Subject: [15] RFR: 8236595: Add more comments about how to setup simulated NVRAM before run java/nio/MappedByteBuffer/PmemTest.java Message-ID: <0A0D0788-D935-463D-9257-552D56BD4F8D@oracle.com> Please have a review for below comments change only to manual test java/nio/MappedByteBuffer/PmemTest.java, the motivation is to make the pre-config steps for setup simulated NVRAM device more clear to newbie, thanks JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8236595 Webrev: http://cr.openjdk.java.net/~xyin/8236595/webrev.00/ Patch: --- old/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 12:47:34.000000000 +0800 +++ new/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 12:47:34.000000000 +0800 @@ -50,10 +50,20 @@ * * https://developers.redhat.com/blog/2016/12/05/configuring-and-using-persistent-memory-rhel-7-3/ * https://nvdimm.wiki.kernel.org/ - * TL;DR: add "memmap=1G!4G" to /etc/default/grub, - * then grub2-mkconfig -o /boot/grub2/grub.cfg and reboot + * TL;DR: add "memmap=1G!4G" to /etc/default/grub, eg. GRUB_CMDLINE_LINUX="memmap=1G!4G" + * then ("sudo" may required) + * for RHEL(BIOS-based): grub2-mkconfig -o /boot/grub2/grub.cfg + * for RHEL(UEFI-based): grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg + * for Ubuntu: update-grub2 + * finally reboot + * after the host been rebooted, a new /dev/pmem{N} device should exist, + * naming conversion starts at /dev/pmem0 + * + * Prepare test directory follow below commands, "sudo" may required + * (if ndctl or mkfs.xfs not exist, install ndctl or xfsprogs package first) + * (for RHEL8, when call mkfs.xfs, specify the -m reflink=0 option to disable reflink feature) * - * ndctl create-namespace * -f -e namespace0.0 -m memory -M mem + * ndctl create-namespace -f -e namespace0.0 -m memory -M mem * mkdir /mnt/pmem * mkfs.xfs -f /dev/pmem0; mount -o dax /dev/pmem0 /mnt/pmem/ * mkdir /mnt/pmem/test; chmod a+rwx /mnt/pmem/test Regards, Chris