From Alan.Bateman at oracle.com Sun Mar 2 03:07:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Mar 2014 11:07:44 +0000 Subject: 8010194: java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh fails with "Timed out waiting ..." (sol) Message-ID: <53131100.4080704@oracle.com> This test has had a bumpy ride during the removal of the Solaris 32-bit builds and the subsequent removal of the ISA (sparcv9 and amd64) links. The test is currently failing in jdk9/dev with solaris-sparcv9 builds and needs to be updated to exec bin/java rather than bin/sparcv9/java. It's a trivial change. Note that this test cannot be changed to use the testlibrary ProcessTools as this test emulates launching from inet or xinetd. http://cr.openjdk.java.net/~alanb/8010194/webrev/ Thanks, Alan. From chris.hegarty at oracle.com Sun Mar 2 04:49:04 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 2 Mar 2014 12:49:04 +0000 Subject: 8010194: java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh fails with "Timed out waiting ..." (sol) In-Reply-To: <53131100.4080704@oracle.com> References: <53131100.4080704@oracle.com> Message-ID: <07E7FAEC-A0DD-47F2-9285-223E83868322@oracle.com> Thank you for fixing this Alan. The changes look good to me. -Chris > On 2 Mar 2014, at 11:07, Alan Bateman wrote: > > > This test has had a bumpy ride during the removal of the Solaris 32-bit builds and the subsequent removal of the ISA (sparcv9 and amd64) links. > > The test is currently failing in jdk9/dev with solaris-sparcv9 builds and needs to be updated to exec bin/java rather than bin/sparcv9/java. It's a trivial change. Note that this test cannot be changed to use the testlibrary ProcessTools as this test emulates launching from inet or xinetd. > > http://cr.openjdk.java.net/~alanb/8010194/webrev/ > > Thanks, > Alan. From mark.sheppard at oracle.com Thu Mar 13 18:59:44 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 13 Mar 2014 18:59:44 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions Message-ID: <53220020.4020005@oracle.com> Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036134/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036134 summary: modification to logic flow to handle JNI pending exception regards Mark From Alan.Bateman at oracle.com Fri Mar 14 13:04:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Mar 2014 13:04:40 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: <53220020.4020005@oracle.com> References: <53220020.4020005@oracle.com> Message-ID: <5322FE68.2080009@oracle.com> On 13/03/2014 18:59, Mark Sheppard wrote: > Hi > Please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8036134/webrev/ > > which address the issues raised in > https://bugs.openjdk.java.net/browse/JDK-8036134 > > summary: > modification to logic flow to handle JNI pending exception If malloc fails then it doesn't throw JNU_ThrowOutOfMemoryError but otherwise I'm not sure that I see a problem. Is the bug report for the case that GetFinalPathNameByHandle fails when calls with the larger buffer? -Alan From mark.sheppard at oracle.com Fri Mar 14 13:38:58 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 14 Mar 2014 13:38:58 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: <5322FE68.2080009@oracle.com> References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> Message-ID: <53230672.4080301@oracle.com> Hi Alan, OK .. I thought I added a JNU_ThrowOutOfMemoryError for the malloc, as I've done with others the other complaint in on the last throwWindowsException, could have a pending exception from previous throwWindowsException, so modified the flow, rather than add an ExceptionCheck. Looking at it again, I don't think the flow is as I intended, as a returns values from Windows API calls are 0 and > 0, no < 0 case!! Let me revisit it regards Mark On 14/03/2014 13:04, Alan Bateman wrote: > On 13/03/2014 18:59, Mark Sheppard wrote: >> Hi >> Please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8036134/webrev/ >> >> which address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8036134 >> >> summary: >> modification to logic flow to handle JNI pending exception > If malloc fails then it doesn't throw JNU_ThrowOutOfMemoryError but > otherwise I'm not sure that I see a problem. Is the bug report for the > case that GetFinalPathNameByHandle fails when calls with the larger > buffer? > > -Alan From mark.sheppard at oracle.com Fri Mar 14 16:55:00 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 14 Mar 2014 16:55:00 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: <5322FE68.2080009@oracle.com> References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> Message-ID: <53233464.2020304@oracle.com> updated changes for review at http://cr.openjdk.java.net/~msheppar/8036134/webrev.01/ regards Mark On 14/03/2014 13:04, Alan Bateman wrote: > On 13/03/2014 18:59, Mark Sheppard wrote: >> Hi >> Please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8036134/webrev/ >> >> which address the issues raised in >> https://bugs.openjdk.java.net/browse/JDK-8036134 >> >> summary: >> modification to logic flow to handle JNI pending exception > If malloc fails then it doesn't throw JNU_ThrowOutOfMemoryError but > otherwise I'm not sure that I see a problem. Is the bug report for the > case that GetFinalPathNameByHandle fails when calls with the larger > buffer? > > -Alan From chris.hegarty at oracle.com Fri Mar 14 17:10:29 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 14 Mar 2014 17:10:29 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: <53233464.2020304@oracle.com> References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> <53233464.2020304@oracle.com> Message-ID: Looks ok to me Mark. -Chris. On 14 Mar 2014, at 16:55, Mark Sheppard wrote: > > updated changes for review at > http://cr.openjdk.java.net/~msheppar/8036134/webrev.01/ > > regards > Mark > > On 14/03/2014 13:04, Alan Bateman wrote: >> On 13/03/2014 18:59, Mark Sheppard wrote: >>> Hi >>> Please oblige and review the following changes >>> http://cr.openjdk.java.net/~msheppar/8036134/webrev/ >>> >>> which address the issues raised in >>> https://bugs.openjdk.java.net/browse/JDK-8036134 >>> >>> summary: >>> modification to logic flow to handle JNI pending exception >> If malloc fails then it doesn't throw JNU_ThrowOutOfMemoryError but otherwise I'm not sure that I see a problem. Is the bug report for the case that GetFinalPathNameByHandle fails when calls with the larger buffer? >> >> -Alan > From mark.sheppard at oracle.com Fri Mar 14 17:17:29 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 14 Mar 2014 17:17:29 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> <53233464.2020304@oracle.com> Message-ID: <532339A9.206@oracle.com> Chris thanks for the review M. On 14/03/2014 17:10, Chris Hegarty wrote: > Looks ok to me Mark. > > -Chris. > > On 14 Mar 2014, at 16:55, Mark Sheppard wrote: > >> updated changes for review at >> http://cr.openjdk.java.net/~msheppar/8036134/webrev.01/ >> >> regards >> Mark >> >> On 14/03/2014 13:04, Alan Bateman wrote: >>> On 13/03/2014 18:59, Mark Sheppard wrote: >>>> Hi >>>> Please oblige and review the following changes >>>> http://cr.openjdk.java.net/~msheppar/8036134/webrev/ >>>> >>>> which address the issues raised in >>>> https://bugs.openjdk.java.net/browse/JDK-8036134 >>>> >>>> summary: >>>> modification to logic flow to handle JNI pending exception >>> If malloc fails then it doesn't throw JNU_ThrowOutOfMemoryError but otherwise I'm not sure that I see a problem. Is the bug report for the case that GetFinalPathNameByHandle fails when calls with the larger buffer? >>> >>> -Alan From Alan.Bateman at oracle.com Sat Mar 15 07:16:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 15 Mar 2014 07:16:02 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: <53233464.2020304@oracle.com> References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> <53233464.2020304@oracle.com> Message-ID: <5323FE32.4060103@oracle.com> On 14/03/2014 16:55, Mark Sheppard wrote: > > updated changes for review at > http://cr.openjdk.java.net/~msheppar/8036134/webrev.01/ Thanks for the update, this looks good now. -Alan From alexey.utkin at gmail.com Sat Mar 15 09:27:13 2014 From: alexey.utkin at gmail.com (Alexey Utkin) Date: Sat, 15 Mar 2014 13:27:13 +0400 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: <5323FE32.4060103@oracle.com> References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> <53233464.2020304@oracle.com> <5323FE32.4060103@oracle.com> Message-ID: The fix still breaks "error first" checking convention, but it looks good and solves the problem. Thanks. -uta On Sat, Mar 15, 2014 at 11:16 AM, Alan Bateman wrote: > On 14/03/2014 16:55, Mark Sheppard wrote: >> >> >> updated changes for review at >> http://cr.openjdk.java.net/~msheppar/8036134/webrev.01/ > > Thanks for the update, this looks good now. > > -Alan From mark.sheppard at oracle.com Sat Mar 15 09:34:43 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Sat, 15 Mar 2014 09:34:43 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: <5323FE32.4060103@oracle.com> References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> <53233464.2020304@oracle.com> <5323FE32.4060103@oracle.com> Message-ID: <53241EB3.6020505@oracle.com> Thanks Alan On 15/03/2014 07:16, Alan Bateman wrote: > On 14/03/2014 16:55, Mark Sheppard wrote: >> >> updated changes for review at >> http://cr.openjdk.java.net/~msheppar/8036134/webrev.01/ > Thanks for the update, this looks good now. > > -Alan From mark.sheppard at oracle.com Sat Mar 15 09:42:52 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Sat, 15 Mar 2014 09:42:52 +0000 Subject: RFR: JDK-8036134 - Check src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c for JNI pending exceptions In-Reply-To: References: <53220020.4020005@oracle.com> <5322FE68.2080009@oracle.com> <53233464.2020304@oracle.com> <5323FE32.4060103@oracle.com> Message-ID: <5324209C.9070807@oracle.com> Thanks Alexey ... that's true, but I usually approach such fixes to make the minimal number of changes and least intrusive changes regards Mark On 15/03/2014 09:27, Alexey Utkin wrote: > The fix still breaks "error first" checking convention, but it looks > good and solves the problem. > Thanks. > -uta > > On Sat, Mar 15, 2014 at 11:16 AM, Alan Bateman wrote: >> On 14/03/2014 16:55, Mark Sheppard wrote: >>> >>> updated changes for review at >>> http://cr.openjdk.java.net/~msheppar/8036134/webrev.01/ >> Thanks for the update, this looks good now. >> >> -Alan From Alan.Bateman at oracle.com Mon Mar 17 10:04:36 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Mar 2014 10:04:36 +0000 Subject: RFR for JDK-8031563: TEST_BUG: java/nio/channels/Selector/ChangingInterests.java failed once In-Reply-To: <52FB7868.3080907@oracle.com> References: <52FB60AB.4070708@oracle.com> <52FB7868.3080907@oracle.com> Message-ID: <5326C8B4.9080801@oracle.com> On 12/02/2014 13:34, michael cui wrote: > Hi, > > Please review two suggested fixes for > > https://bugs.openjdk.java.net/browse/JDK-8031563 > > Root cause: selectNow is called right after 50 milliseconds sleep in > write1 method which may not be sufficient to make the socket channel > readable in some situation. Since selectNow called only once and > verification based on its result will fail if readable event wasn't > ready at that time. Sorry for the delay getting to this one, I've been busy with other things. The primary purpose of the test is to exercise each of the possible transitions and to check that the Selector doesn't spin. If we change the test as per your webrev_v2 then it means there is no guarantee that we exercise the transition to OP_READ + OP_WRITE as originally intended. As it will be exercised most of the time then it might be okay but it would clearly desirable for this transition to be testable each time. Looking at the test now then I just wonder if perhaps the issue is that it doesn't set TCP_NODELAY to disable the Nagle algorithm. I haven't been able to reproduce the issue and I'm curious if you have been able to. If you are then I'd be interested to know setting TCP_NODELAY to true after accepting the connection will resolve the issue. -Alan. From fgaliegue at gmail.com Sat Mar 22 00:56:42 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 22 Mar 2014 01:56:42 +0100 Subject: Bug on at least Linux, Mac OS X with Paths.get("").normalize() Message-ID: Hello, I am currently writing a FileSystem implementation for FTP and while testing the nooks and crannies of the API, I stumbled upon this bug. This very simple main(): ---- import java.nio.file.Paths; public class Foo { public static void main(final String... args) { System.out.println(Paths.get("").normalize()); } } ---- results in: ---- Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.nio.fs.UnixPath.normalize(UnixPath.java:508) at Foo.main(Foo.java:7) ---- Confirmed to "work" on Mac OS X; what is more, this affects both Java 7 and Java 8. Regards, -- Francis Galiegue, fgaliegue at gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From Alan.Bateman at oracle.com Sat Mar 22 08:05:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Mar 2014 08:05:19 +0000 Subject: Bug on at least Linux, Mac OS X with Paths.get("").normalize() In-Reply-To: References: Message-ID: <532D443F.10004@oracle.com> On 22/03/2014 00:56, Francis Galiegue wrote: > : > > ---- > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > at sun.nio.fs.UnixPath.normalize(UnixPath.java:508) > at Foo.main(Foo.java:7) > ---- > > Confirmed to "work" on Mac OS X; what is more, this affects both Java > 7 and Java 8. > Thanks, someone else reported the same thing this week: https://bugs.openjdk.java.net/browse/JDK-8037945 It's an oversight but easily fixed. -Alan. From fgaliegue at gmail.com Sat Mar 22 08:25:53 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 22 Mar 2014 09:25:53 +0100 Subject: Bug on at least Linux, Mac OS X with Paths.get("").normalize() In-Reply-To: <532D443F.10004@oracle.com> References: <532D443F.10004@oracle.com> Message-ID: On Sat, Mar 22, 2014 at 9:05 AM, Alan Bateman wrote: > On 22/03/2014 00:56, Francis Galiegue wrote: >> >> : >> >> ---- >> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 >> at sun.nio.fs.UnixPath.normalize(UnixPath.java:508) >> at Foo.main(Foo.java:7) >> ---- >> >> Confirmed to "work" on Mac OS X; what is more, this affects both Java >> 7 and Java 8. >> > Thanks, someone else reported the same thing this week: > > https://bugs.openjdk.java.net/browse/JDK-8037945 > > It's an oversight but easily fixed. > Hello, Well, that was me... I had to use sun.bugs.com, and as it doesn't send email confirmations back, I subscribed here. Sorry for the noise... -- Francis Galiegue, fgaliegue at gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From fgaliegue at gmail.com Sat Mar 22 08:45:01 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 22 Mar 2014 09:45:01 +0100 Subject: Oversight in documentation about the behaviour of .resolve{Sibling}() and .relativize()? Message-ID: Hello, I am in the process of implementing a FileSystem over FTP, so I experimented with some not-that-much-used stuff and discovered that if you try and p1.resolve(p2), where p1 and p2 are Paths issued from different FileSystems, you get a ProviderMismatchException. I discovered it the hard way, since this is not documented! Can this be documented in future JDK releases? Also, since this is FTP, I don't have any "device" size information about the other end; the javadoc of FileStore doesn't tell what the .get*Space() methods return in this case. RIght now I return Long.MAX_VALUE. Is that OK? And can the behaviour in this case be documented as well? Regards, -- Francis Galiegue, fgaliegue at gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From Alan.Bateman at oracle.com Sat Mar 22 09:04:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Mar 2014 09:04:06 +0000 Subject: Oversight in documentation about the behaviour of .resolve{Sibling}() and .relativize()? In-Reply-To: References: Message-ID: <532D5206.90108@oracle.com> On 22/03/2014 08:45, Francis Galiegue wrote: > Hello, > > I am in the process of implementing a FileSystem over FTP, so I > experimented with some not-that-much-used stuff and discovered that if > you try and p1.resolve(p2), where p1 and p2 are Paths issued from > different FileSystems, you get a ProviderMismatchException. > > I discovered it the hard way, since this is not documented! Can this > be documented in future JDK releases? The package description documents the general exceptions that are possible. It includes this: "Unless otherwise noted, invoking a method of any class or interface in this package created by one provider with a parameter that is an object created by another provider, will throw ProviderMismatchException." > : > > Also, since this is FTP, I don't have any "device" size information > about the other end; the javadoc of FileStore doesn't tell what the > .get*Space() methods return in this case. > Originally FileStore didn't define the getXXXSpace methods but there were complaints that this this made it harder to use because it required getting the appropriate FileStoreAttributeView. Potentially we could allow for these methods to return -1 when the size it unknown. Alternatively if you can't really implement FileStore then the FileSystemProvider's getFileStore could fail. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Sat Mar 22 09:23:44 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 22 Mar 2014 10:23:44 +0100 Subject: Oversight in documentation about the behaviour of .resolve{Sibling}() and .relativize()? In-Reply-To: <532D5206.90108@oracle.com> References: <532D5206.90108@oracle.com> Message-ID: On Sat, Mar 22, 2014 at 10:04 AM, Alan Bateman wrote: [...] > > The package description documents the general exceptions that are possible. > It includes this: > > "Unless otherwise noted, invoking a method of any class or interface in this > package created by one provider with a parameter that is an object created > by another provider, will throw ProviderMismatchException." > OK, admittedly I didn't read the package description and should have. Still, it is not very visible for "casual" users... [...] > > Originally FileStore didn't define the getXXXSpace methods but there were > complaints that this this made it harder to use because it required getting > the appropriate FileStoreAttributeView. Potentially we could allow for these > methods to return -1 when the size it unknown. Alternatively if you can't > really implement FileStore then the FileSystemProvider's getFileStore could > fail. > With UnsupportedOperationException? Regards, -- Francis Galiegue, fgaliegue at gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From Alan.Bateman at oracle.com Sun Mar 23 17:24:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Mar 2014 17:24:17 +0000 Subject: Oversight in documentation about the behaviour of .resolve{Sibling}() and .relativize()? In-Reply-To: References: <532D5206.90108@oracle.com> Message-ID: <532F18C1.1080904@oracle.com> On 22/03/2014 09:23, Francis Galiegue wrote: > : > OK, admittedly I didn't read the package description and should have. > Still, it is not very visible for "casual" users... True but at the same time it can be annoying for every method to document NullPointerException, ClosedFileSystemException, ... In the case of ProviderMismatchException then it might be beneficial to repeat the statement in Path's class description, that might improve the chances of it being noticed for the few cases that it might arise. > > With UnsupportedOperationException? > That would be best. As you'll see then UOE is already specification by several of the methods defined by FileSystemProvider. -Alan From Alan.Bateman at oracle.com Mon Mar 24 13:24:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Mar 2014 13:24:14 +0000 Subject: 8037945: Paths.get("").normalize() throws ArrayIndexOutOfBoundsException Message-ID: <533031FE.2090000@oracle.com> This is the issue that Francis Galiegue brought up a few days. It's an oversight in the original implementation and surprising that we didn't have a test for this case. Windows is not affected and the Windows specific tests already cover this case. http://cr.openjdk.java.net/~alanb/8037945/webrev/ -Alan. From chris.hegarty at oracle.com Mon Mar 24 14:06:23 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Mar 2014 14:06:23 +0000 Subject: 8037945: Paths.get("").normalize() throws ArrayIndexOutOfBoundsException In-Reply-To: <533031FE.2090000@oracle.com> References: <533031FE.2090000@oracle.com> Message-ID: <53303BDF.9050308@oracle.com> Looks good to me. And good to have a test for this now. -Chris. On 24/03/14 13:24, Alan Bateman wrote: > > This is the issue that Francis Galiegue brought up a few days. It's an > oversight in the original implementation and surprising that we didn't > have a test for this case. Windows is not affected and the Windows > specific tests already cover this case. > > http://cr.openjdk.java.net/~alanb/8037945/webrev/ > > -Alan. From michael.cui at oracle.com Tue Mar 25 07:56:39 2014 From: michael.cui at oracle.com (michael cui) Date: Tue, 25 Mar 2014 15:56:39 +0800 Subject: RFR for JDK-8031563: TEST_BUG: java/nio/channels/Selector/ChangingInterests.java failed once In-Reply-To: <5326C8B4.9080801@oracle.com> References: <52FB60AB.4070708@oracle.com> <52FB7868.3080907@oracle.com> <5326C8B4.9080801@oracle.com> Message-ID: <533136B7.5040804@oracle.com> Hi Alan, Thank you very much for review, please see my comments inline : On 03/17/2014 06:04 PM, Alan Bateman wrote: > On 12/02/2014 13:34, michael cui wrote: > The primary purpose of the test is to exercise each of the possible > transitions and to check that the Selector doesn't spin. If we change > the test as per your webrev_v2 then it means there is no guarantee > that we exercise the transition to OP_READ + OP_WRITE as originally > intended. As it will be exercised most of the time then it might be > okay but it would clearly desirable for this transition to be testable > each time. My understanding is the transition combination is formed by two for-loops and there is no change for that. The change I made in testChange method will try to call selector.selectNow() more than once if and only if (transition is OP_READ + OP_WRITE) and (either read event or write event didn't arrive at moment of calling selectNow ). Anyway, this code change won't fix the issue. The fix you suggested is the right solution. > > Looking at the test now then I just wonder if perhaps the issue is > that it doesn't set TCP_NODELAY to disable the Nagle algorithm. I > haven't been able to reproduce the issue and I'm curious if you have > been able to. If you are then I'd be interested to know setting > TCP_NODELAY to true after accepting the connection will resolve the > issue. That's should be the root cause and should fix the issue. I updated code based on your suggestion. Please review the fix at http://cr.openjdk.java.net/~ewang/michael/JDK-8031563/webrev.00/ Test had been done on Window, Mac, Linux and Solaris. No failure was found during 2000 runs on each platform. > > -Alan. Thanks, Michael Cui From Alan.Bateman at oracle.com Tue Mar 25 10:12:36 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Mar 2014 10:12:36 +0000 Subject: RFR for JDK-8031563: TEST_BUG: java/nio/channels/Selector/ChangingInterests.java failed once In-Reply-To: <533136B7.5040804@oracle.com> References: <52FB60AB.4070708@oracle.com> <52FB7868.3080907@oracle.com> <5326C8B4.9080801@oracle.com> <533136B7.5040804@oracle.com> Message-ID: <53315694.7020408@oracle.com> On 25/03/2014 07:56, michael cui wrote: > : > > I updated code based on your suggestion. Please review the fix at > http://cr.openjdk.java.net/~ewang/michael/JDK-8031563/webrev.00/ > > Test had been done on Window, Mac, Linux and Solaris. No failure was > found during 2000 runs on each platform. Thanks for taking on the suggestion, the change looks good to me. -Alan From fgaliegue at gmail.com Sat Mar 29 11:06:39 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 29 Mar 2014 12:06:39 +0100 Subject: "Big" mapping support in future versions of Java? Message-ID: Hello, One limit of Java, even in 8, is the inability to map files over 2 GB in one go; because of the definition of ByteBuffer, indices are limited to ints; even though arguments to FileChannel.map() are longs. Is there a plan to create a new set of classes in the future which would remove this limitation? -- Francis Galiegue, fgaliegue at gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From weijun.wang at oracle.com Mon Mar 31 02:51:22 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 31 Mar 2014 10:51:22 +0800 Subject: newDirectoryStream(dir) for absolute dir always returns absolute paths? Message-ID: <2D943B2F-B96C-416C-ABB1-1B7E77692FCE@oracle.com> If dir is absolute, can I be sure that path elements in newDirectoryStream(dir) are also absolute? Thanks Max From fgaliegue at gmail.com Mon Mar 31 05:01:36 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 31 Mar 2014 07:01:36 +0200 Subject: newDirectoryStream(dir) for absolute dir always returns absolute paths? In-Reply-To: <2D943B2F-B96C-416C-ABB1-1B7E77692FCE@oracle.com> References: <2D943B2F-B96C-416C-ABB1-1B7E77692FCE@oracle.com> Message-ID: Hello, On Mon, Mar 31, 2014 at 4:51 AM, Wang Weijun wrote: > If dir is absolute, can I be sure that path elements in newDirectoryStream(dir) are also absolute? > The doc says so at least, in Java 7 and 8: " The Path objects are obtained as if by resolving the name of the directory entry against dir. " (where "dir" is the Path argument) Therefore, yes, you can guarantee that. -- Francis Galiegue, fgaliegue at gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From Alan.Bateman at oracle.com Mon Mar 31 10:42:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 31 Mar 2014 11:42:18 +0100 Subject: "Big" mapping support in future versions of Java? In-Reply-To: References: Message-ID: <5339468A.5040908@oracle.com> On 29/03/2014 11:06, Francis Galiegue wrote: > Hello, > > One limit of Java, even in 8, is the inability to map files over 2 GB > in one go; because of the definition of ByteBuffer, indices are > limited to ints; even though arguments to FileChannel.map() are longs. > > Is there a plan to create a new set of classes in the future which > would remove this limitation? > Back in JSR 203 / JDK 7 we did prototype a parallel hierarchy of large buffers that used a long to index elements but it is ugly and we didn't take this approach very far. It is an issue that will need to looked at again sometime, possibility by allowing a file mapping to back a big array or collection of primitive types. Nothing specifically planned at moment (at least not to my knowledge). -Alan.