From Alan.Bateman at oracle.com Sat Dec 1 08:17:49 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 01 Dec 2012 16:17:49 +0000 Subject: Review Request: JDK-7142921,(fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04 In-Reply-To: <50B8DEC8.7040001@oracle.com> References: <50B30EC2.4060202@oracle.com> <50B372B4.3000401@oracle.com> <50B3C324.8070408@oracle.com> <50B40EFD.7020409@oracle.com> <50B4CF9C.5000800@oracle.com> <50B5684A.1030309@oracle.com> <50B5F518.3080509@oracle.com> <50B7127C.808@oracle.com> <50B7A16E.3070900@oracle.com> <50B8DEC8.7040001@oracle.com> Message-ID: <50BA2DAD.3030301@oracle.com> On 30/11/2012 16:28, Dan Xu wrote: > Thanks for your comments. Here is the updated patch, > http://cr.openjdk.java.net/~dxu/7142921/webrev.03/ > . Please review it. > > -Dan Thanks for the fixing the lazy loading to loadMimeTypes. Minor comment is that you don't really need "done". I don't think L108-111 is needed as Files.readAllLines will fail the file can't be found. You will need to do this in a doPrivileged block as otherwise it will fail if there is a security manager. This also means you don't need to catch SecurityException. The test update is missing in this webrev, I don't know if that is intentional or not. I did a quick check and it looks like we aren't testing Files.probeContentType with a security manager and I think it would be good to add such a test. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121201/e7022138/attachment.html From dan.xu at oracle.com Sun Dec 2 00:04:08 2012 From: dan.xu at oracle.com (Dan Xu) Date: Sun, 02 Dec 2012 00:04:08 -0800 Subject: In-Reply-To: <> References: <50B30EC2.4060202@oracle.com> <50B372B4.3000401@oracle.com> <50B3C324.8070408@oracle.com> <50B40EFD.7020409@oracle.com> <50B4CF9C.5000800@oracle.com> <50B5684A.1030309@oracle.com> <50B5F518.3080509@oracle.com> <50B7127C.808@oracle.com> <50B7A16E.3070900@oracle.com> <50B8DEC8.7040001@oracle.com> <> Message-ID: <50BB0B78.2070308@oracle.com> Hi Alan, I just uploaded the new fix at http://cr.openjdk.java.net/~dxu/7142921/webrev.04/. Please help take a look. I forgot to add the testcase in my last webrev. And now I updated CheckPermissions.java with a section to test Files.probeContentType() at the end of main() method. Another minor change I did is to add "mimeTypesFile != null" in the if condition in loadMimeTypes() method. Otherwise, it may throw a NullPointException. In addition, I am still not very clear about the usage of doPrivileged block. In my understanding, all code shipped inside JDK is considered system code and run inside the system domain, which automatically has full permissions. Why do we still use doPrivileged block to bypass the security manager? Thanks, -Dan On Sat 01 Dec 2012 08:17:49 AM PST, Alan Bateman wrote: > On 30/11/2012 16:28, Dan Xu wrote: >> Thanks for your comments. Here is the updated patch, >> http://cr.openjdk.java.net/~dxu/7142921/webrev.03/ >> . Please review it. >> >> -Dan > Thanks for the fixing the lazy loading to loadMimeTypes. Minor comment > is that you don't really need "done". > > I don't think L108-111 is needed as Files.readAllLines will fail the > file can't be found. You will need to do this in a doPrivileged block > as otherwise it will fail if there is a security manager. This also > means you don't need to catch SecurityException. > > The test update is missing in this webrev, I don't know if that is > intentional or not. I did a quick check and it looks like we aren't > testing Files.probeContentType with a security manager and I think it > would be good to add such a test. > > -Alan. From zhouyx at linux.vnet.ibm.com Tue Dec 4 02:53:04 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Tue, 4 Dec 2012 18:53:04 +0800 Subject: Should java/nio/channels/spi/AbstractInterruptibleChannel.java#isOpen be synchronized ? Message-ID: Hello, I found AbstractInterruptibleChannel.close() is synchronized using closeLock, but isOpen() is not synchronized. Javadoc of isOpen() says "Returns: true if, and only if, this channel is open". I want to know if isOpen() method is designed not to synchronize with closeLock ? Because in close() method the closeLock embraces "open = false;" and " implCloseChannel(); " , which looks like the open variable should always reflect the real state. -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121204/72d79747/attachment.html From Alan.Bateman at oracle.com Tue Dec 4 06:09:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Dec 2012 14:09:52 +0000 Subject: Review Request: JDK-7142921,(fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04 In-Reply-To: <50BB0B78.2070308@oracle.com> References: <50B30EC2.4060202@oracle.com> <50B372B4.3000401@oracle.com> <50B3C324.8070408@oracle.com> <50B40EFD.7020409@oracle.com> <50B4CF9C.5000800@oracle.com> <50B5684A.1030309@oracle.com> <50B5F518.3080509@oracle.com> <50B7127C.808@oracle.com> <50B7A16E.3070900@oracle.com> <50B8DEC8.7040001@oracle.com> <> <50BB0B78.2070308@oracle.com> Message-ID: <50BE0430.2020600@oracle.com> On 02/12/2012 08:04, Dan Xu wrote: > Hi Alan, > > I just uploaded the new fix at > http://cr.openjdk.java.net/~dxu/7142921/webrev.04/. Please help take a > look. I think this looks good now and addresses the issues that we've discussed here. I grabbed your patch and just tied up a few things, the updated webrev is here: http://cr.openjdk.java.net/~alanb/7142921/webrev/index.html I'll get this pushed today. -Alan From Alan.Bateman at oracle.com Tue Dec 4 06:13:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Dec 2012 14:13:16 +0000 Subject: Should java/nio/channels/spi/AbstractInterruptibleChannel.java#isOpen be synchronized ? In-Reply-To: References: Message-ID: <50BE04FC.50000@oracle.com> On 04/12/2012 10:53, Sean Chou wrote: > Hello, > > I found AbstractInterruptibleChannel.close() is synchronized > using closeLock, but isOpen() is not synchronized. Javadoc > of isOpen() says "Returns: true if, and only if, this channel is > open". I want to know if isOpen() method is designed not to > synchronize with closeLock ? Because in close() method the closeLock > embraces "open = false;" and " implCloseChannel(); " , which looks > like the open variable should always reflect the real state. What problem are you running into? I see anything wrong with isOpen and it would create a lot of issues if it were to synchronize on closeLock. -Alan From chris.hegarty at oracle.com Tue Dec 4 06:38:19 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 04 Dec 2012 14:38:19 +0000 Subject: Should java/nio/channels/spi/AbstractInterruptibleChannel.java#isOpen be synchronized ? In-Reply-To: <50BE04FC.50000@oracle.com> References: <50BE04FC.50000@oracle.com> Message-ID: <50BE0ADB.8090903@oracle.com> On 12/04/2012 02:13 PM, Alan Bateman wrote: > On 04/12/2012 10:53, Sean Chou wrote: >> Hello, >> >> I found AbstractInterruptibleChannel.close() is synchronized using >> closeLock, but isOpen() is not synchronized. Javadoc of isOpen() says >> "Returns: true if, and only if, this channel is open". I want to know >> if isOpen() method is designed not to synchronize with closeLock ? >> Because in close() method the closeLock embraces "open = false;" and " >> implCloseChannel(); " , which looks like the open variable should >> always reflect the real state. > What problem are you running into? I see anything wrong with isOpen and > it would create a lot of issues if it were to synchronize on closeLock. I also don't see any issue. Since 'open' is volatile, visibility is guaranteed. Yes, this is racy code, but that's the nature of asynchronous close/interrupt. -Chris. > > -Alan From zhouyx at linux.vnet.ibm.com Tue Dec 4 18:47:24 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Wed, 5 Dec 2012 10:47:24 +0800 Subject: Should java/nio/channels/spi/AbstractInterruptibleChannel.java#isOpen be synchronized ? In-Reply-To: <50BE0ADB.8090903@oracle.com> References: <50BE04FC.50000@oracle.com> <50BE0ADB.8090903@oracle.com> Message-ID: A small problem I'm still checking. So the closeLock is just to make sure the channel is closed only once, is that right? On Tue, Dec 4, 2012 at 10:38 PM, Chris Hegarty wrote: > On 12/04/2012 02:13 PM, Alan Bateman wrote: > >> On 04/12/2012 10:53, Sean Chou wrote: >> >>> Hello, >>> >>> I found AbstractInterruptibleChannel.**close() is synchronized using >>> closeLock, but isOpen() is not synchronized. Javadoc of isOpen() says >>> "Returns: true if, and only if, this channel is open". I want to know >>> if isOpen() method is designed not to synchronize with closeLock ? >>> Because in close() method the closeLock embraces "open = false;" and " >>> implCloseChannel(); " , which looks like the open variable should >>> always reflect the real state. >>> >> What problem are you running into? I see anything wrong with isOpen and >> it would create a lot of issues if it were to synchronize on closeLock. >> > > I also don't see any issue. Since 'open' is volatile, visibility is > guaranteed. Yes, this is racy code, but that's the nature of asynchronous > close/interrupt. > > -Chris. > > >> -Alan >> > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121205/d5580a78/attachment.html From Alan.Bateman at oracle.com Wed Dec 5 02:10:41 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Dec 2012 10:10:41 +0000 Subject: Should java/nio/channels/spi/AbstractInterruptibleChannel.java#isOpen be synchronized ? In-Reply-To: References: <50BE04FC.50000@oracle.com> <50BE0ADB.8090903@oracle.com> Message-ID: <50BF1DA1.2050306@oracle.com> On 05/12/2012 02:47, Sean Chou wrote: > A small problem I'm still checking. So the closeLock is just to make > sure the channel is closed only once, is that right? This is how close is specified: "If this channel is already closed then invoking this method has no effect. This method may be invoked at any time. If some other thread has already invoked it, however, then another invocation will block until the first invocation is complete, after which it will return without effect." -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121205/ebab5cb4/attachment.html From philippe.marschall at gmail.com Fri Dec 7 15:05:49 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sat, 8 Dec 2012 00:05:49 +0100 Subject: Zip file system provider only works with default file system Message-ID: Hi First, I hope I got the right mailing list. I'm in the process of writing my own file system provider. As a test I wanted to create a zip file on it using the zip file system provider. That's when I discovered that it only works with the default file system. The culprit is the following method in ZipFileSystem: // Creates a new empty temporary file in the same directory as the // specified file. A variant of File.createTempFile. private Path createTempFileInSameDirectoryAs(Path path) throws IOException { Path parent = path.toAbsolutePath().getParent(); String dir = (parent == null)? "." : parent.toString(); Path tmpPath = File.createTempFile("zipfstmp", null, new File(dir)).toPath(); tmppaths.add(tmpPath); return tmpPath; } I unnecessarily uses File.createTempFile when Files.createTempFile would be available as an alternative that works with every file system provider. I assume something like this should work. // Creates a new empty temporary file in the same directory as the // specified file. A variant of Files.createTempFile. private Path createTempFileInSameDirectoryAs(Path path) throws IOException { Path parent = path.toAbsolutePath().getParent(); Path dir = (parent == null)? path.getFileSystem().getPath(".") : parent; Path tmpPath = Files.createTempFile(dir, "zipfstmp", null); tmppaths.add(tmpPath); return tmpPath; } I did not actually build a JDK and test this code. Cheers Philippe From dan.xu at oracle.com Fri Dec 7 16:03:52 2012 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 07 Dec 2012 16:03:52 -0800 Subject: Review Request - JDK-7194370 (fs) WatchService fails if volume S/N is 0 [win] Message-ID: <50C283E8.1040905@oracle.com> Hi folks, Please help review the fix for JDK-7194370,,(fs) WatchService fails if volume S/N is 0 [win]. The webrev is uploaded at, http://cr.openjdk.java.net/~dxu/7194370/webrev/. The issue is because we have an assumption that volumn serial number cannot be 0.The serial number is 32-bit number determined by the date on the currentcomputer at the time of a disk's formatting. It is very rare for a volumnto be assigned a serial number as 0000-0000. But it could happen. The fix is to remove non-zero assertions.Thanks! -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121207/9a16e31f/attachment.html From Alan.Bateman at oracle.com Sat Dec 8 02:29:01 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 08 Dec 2012 10:29:01 +0000 Subject: Review Request - JDK-7194370 (fs) WatchService fails if volume S/N is 0 [win] In-Reply-To: <50C283E8.1040905@oracle.com> References: <50C283E8.1040905@oracle.com> Message-ID: <50C3166D.8090806@oracle.com> On 08/12/2012 00:03, Dan Xu wrote: > Hi folks, > > Please help review the fix for JDK-7194370,,(fs) WatchService fails if > volume S/N is 0 [win]. The webrev is uploaded at, > http://cr.openjdk.java.net/~dxu/7194370/webrev/. > > The issue is because we have an assumption that volumn serial number > cannot be 0.The serial number is 32-bit number determined by the date > on the currentcomputer at the time of a disk's formatting. It is very > rare for a volumnto be assigned a serial number as 0000-0000. But it > could happen. The fix is to remove non-zero assertions.Thanks! > > -Dan Thanks Dan, an oversight in the original implementation. I'll push this for you. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121208/438ff4ec/attachment.html From Alan.Bateman at oracle.com Sat Dec 8 02:52:21 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 08 Dec 2012 10:52:21 +0000 Subject: Zip file system provider only works with default file system In-Reply-To: References: Message-ID: <50C31BE5.5080304@oracle.com> On 07/12/2012 23:05, Philippe Marschall wrote: > Hi > > First, I hope I got the right mailing list. I'm in the process of > writing my own file system provider. As a test I wanted to create a > zip file on it using the zip file system provider. That's when I > discovered that it only works with the default file system. > Thanks for the bug report, It's possible that zip provider has been tested with other providers. Is your provider interposing on the system-default or is a distinct provider? I'm curious how you ran into this. You might know this already but zip provider ships as a demo provider (source code is the demo directory) so it might be easy for you to test your patch and also see if there are any other issues. I think it would be useful to know if there are any other issues. -Alan. From philippe.marschall at gmail.com Sat Dec 8 04:30:19 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sat, 8 Dec 2012 13:30:19 +0100 Subject: Zip file system provider only works with default file system In-Reply-To: <50C31BE5.5080304@oracle.com> References: <50C31BE5.5080304@oracle.com> Message-ID: On Sat, Dec 8, 2012 at 11:52 AM, Alan Bateman wrote: > On 07/12/2012 23:05, Philippe Marschall wrote: >> >> Hi >> >> First, I hope I got the right mailing list. I'm in the process of >> writing my own file system provider. As a test I wanted to create a >> zip file on it using the zip file system provider. That's when I >> discovered that it only works with the default file system. >> > Thanks for the bug report, It's possible that zip provider has been tested > with other providers. Is your provider interposing on the system-default or > is a distinct provider? I'm curious how you ran into this. It's an in-memory file system, completely distinct. > You might know this already but zip provider ships as a demo provider > (source code is the demo directory) so it might be easy for you to test your > patch and also see if there are any other issues. I think it would be useful > to know if there are any other issues. Ok, will do and report back. Cheers Philippe From philippe.marschall at gmail.com Sat Dec 8 05:41:28 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sat, 8 Dec 2012 14:41:28 +0100 Subject: Zip file system provider only works with default file system In-Reply-To: <50C31BE5.5080304@oracle.com> References: <50C31BE5.5080304@oracle.com> Message-ID: On Sat, Dec 8, 2012 at 11:52 AM, Alan Bateman wrote: > On 07/12/2012 23:05, Philippe Marschall wrote: >> >> Hi >> >> First, I hope I got the right mailing list. I'm in the process of >> writing my own file system provider. As a test I wanted to create a >> zip file on it using the zip file system provider. That's when I >> discovered that it only works with the default file system. >> > Thanks for the bug report, It's possible that zip provider has been tested > with other providers. Is your provider interposing on the system-default or > is a distinct provider? I'm curious how you ran into this. To give a bit more context my code looks something like this: public class ZipFileSystemInteropabilityTest { @Rule public final FileSystemRule rule = new FileSystemRule(); @Test public void createZipFileSystem() throws IOException { FileSystem memoryFileSystem = this.rule.getFileSystem(); Map env = Collections.singletonMap("create", "true"); URI uri = URI.create("jar:" + memoryFileSystem.getPath("/file.zip").toUri()); try (FileSystem zipfs = FileSystems.newFileSystem(uri, env)) { try (BufferedWriter writer = Files.newBufferedWriter(zipfs.getPath("hello.txt"), StandardCharsets.US_ASCII, CREATE_NEW, WRITE)) { writer.write("world"); } } } } where memoryFileSystem would be an instance of my custom memory file system and the rule would be a JUnit rule that create a file system before the test and removes it afterward. The exception I get is: java.io.IOException: Permission denied at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createTempFile(File.java:1879) at com.sun.nio.zipfs.ZipFileSystem.createTempFileInSameDirectoryAs(ZipFileSystem.java:1087) at com.sun.nio.zipfs.ZipFileSystem.sync(ZipFileSystem.java:1190) at com.sun.nio.zipfs.ZipFileSystem.close(ZipFileSystem.java:277) at com.acme.memoryfilesystem.ZipFileSystemInteropabilityTest.createZipFileSystem(ZipFileSystemInteropabilityTest.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at com.acme.memoryfilesystem.FileSystemRule$1.evaluate(FileSystemRule.java:28) at .. The problem is that the zip file system provider tries to create a temp file like /zipfstmp5062712090450520532.tmp in the default file system instead of the file system it's running on. And on Unix you generally don't have the permission to create files in the root. Cheers Philippe From xueming.shen at oracle.com Sat Dec 8 11:33:07 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 08 Dec 2012 11:33:07 -0800 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> Message-ID: <50C395F3.2050200@oracle.com> ZFS tries to create a temporary file at the same directory as your zipfile by invoking the File.createTempFile(). Unfortunately the directory passed is the one on your in-memory file system in your use scenario. This need to be re-considered when we update the ZFS. -Sherman On 12/8/12 5:41 AM, Philippe Marschall wrote: > On Sat, Dec 8, 2012 at 11:52 AM, Alan Bateman wrote: >> On 07/12/2012 23:05, Philippe Marschall wrote: >>> Hi >>> >>> First, I hope I got the right mailing list. I'm in the process of >>> writing my own file system provider. As a test I wanted to create a >>> zip file on it using the zip file system provider. That's when I >>> discovered that it only works with the default file system. >>> >> Thanks for the bug report, It's possible that zip provider has been tested >> with other providers. Is your provider interposing on the system-default or >> is a distinct provider? I'm curious how you ran into this. > To give a bit more context my code looks something like this: > > public class ZipFileSystemInteropabilityTest { > > @Rule > public final FileSystemRule rule = new FileSystemRule(); > > @Test > public void createZipFileSystem() throws IOException { > FileSystem memoryFileSystem = this.rule.getFileSystem(); > Map env = Collections.singletonMap("create", "true"); > URI uri = URI.create("jar:" + > memoryFileSystem.getPath("/file.zip").toUri()); > try (FileSystem zipfs = FileSystems.newFileSystem(uri, env)) { > try (BufferedWriter writer = > Files.newBufferedWriter(zipfs.getPath("hello.txt"), > StandardCharsets.US_ASCII, CREATE_NEW, WRITE)) { > writer.write("world"); > } > } > } > > } > > where memoryFileSystem would be an instance of my custom memory file > system and the rule would be a JUnit rule that create a file system > before the test and removes it afterward. > > The exception I get is: > > java.io.IOException: Permission denied > at java.io.UnixFileSystem.createFileExclusively(Native Method) > at java.io.File.createTempFile(File.java:1879) > at com.sun.nio.zipfs.ZipFileSystem.createTempFileInSameDirectoryAs(ZipFileSystem.java:1087) > at com.sun.nio.zipfs.ZipFileSystem.sync(ZipFileSystem.java:1190) > at com.sun.nio.zipfs.ZipFileSystem.close(ZipFileSystem.java:277) > at com.acme.memoryfilesystem.ZipFileSystemInteropabilityTest.createZipFileSystem(ZipFileSystemInteropabilityTest.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at com.acme.memoryfilesystem.FileSystemRule$1.evaluate(FileSystemRule.java:28) > at .. > > The problem is that the zip file system provider tries to create a > temp file like /zipfstmp5062712090450520532.tmp in the default file > system instead of the file system it's running on. And on Unix you > generally don't have the permission to create files in the root. > > Cheers > Philippe From philippe.marschall at gmail.com Sat Dec 8 11:40:40 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sat, 8 Dec 2012 20:40:40 +0100 Subject: Zip file system provider only works with default file system In-Reply-To: <50C395F3.2050200@oracle.com> References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> Message-ID: On Sat, Dec 8, 2012 at 8:33 PM, Xueming Shen wrote: > ZFS tries to create a temporary file at the same directory as your zipfile > by invoking > the File.createTempFile(). But it's done on the wrong file system. ZFS does it no the default file system, instead of the file system the ZIP file resides on. Cheers Philippe From xueming.shen at oracle.com Sat Dec 8 11:54:12 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 08 Dec 2012 11:54:12 -0800 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> Message-ID: <50C39AE4.1070308@oracle.com> On 12/8/12 11:40 AM, Philippe Marschall wrote: > On Sat, Dec 8, 2012 at 8:33 PM, Xueming Shen wrote: >> ZFS tries to create a temporary file at the same directory as your zipfile >> by invoking >> the File.createTempFile(). > But it's done on the wrong file system. ZFS does it no the default > file system, instead of the file system the ZIP file resides on. This is why it's a bug:-) The temp file should be on your memory file system, not the default file system (java.io.File only knows about the default one). So we probably should not use the java.io.File for the temporary file, if we are not on the default file system. -Sherman > > Cheers > Philippe From mik3hall at gmail.com Sat Dec 8 12:18:15 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 8 Dec 2012 14:18:15 -0600 Subject: Zip file system provider only works with default file system In-Reply-To: <50C39AE4.1070308@oracle.com> References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> Message-ID: It's a demo. Couldn't you just temporarily put your own ZipFileSystem in classpath some place before the default version jar? With something like? In com.sun.nio.zipfs.ZipFileSystem // Creates a new empty temporary file in the same directory as the // specified file. A variant of File.createTempFile. private Path createTempFileInSameDirectoryAs(Path path) throws IOException { Path parent = path.toAbsolutePath().getParent(); Path tmpPath = Files.createTempFile(dir,"zipfstmp", null); tmppaths.add(tmpPath); return tmpPath; } Assumes it'll use the correct FileSystem as the parameter's Path all the way through, I haven't tested it at all. Not sure if there are any complications with a com.sun class. You could change the demo package. Are you just trying this out or do you intend to use the demo code in something production? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121208/b42518bc/attachment.html From philippe.marschall at gmail.com Sun Dec 9 06:54:13 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sun, 9 Dec 2012 15:54:13 +0100 Subject: Zip file system provider only works with default file system In-Reply-To: <50C31BE5.5080304@oracle.com> References: <50C31BE5.5080304@oracle.com> Message-ID: On Sat, Dec 8, 2012 at 11:52 AM, Alan Bateman wrote: > On 07/12/2012 23:05, Philippe Marschall wrote: >> >> Hi >> >> First, I hope I got the right mailing list. I'm in the process of >> writing my own file system provider. As a test I wanted to create a >> zip file on it using the zip file system provider. That's when I >> discovered that it only works with the default file system. >> > Thanks for the bug report, It's possible that zip provider has been tested > with other providers. Is your provider interposing on the system-default or > is a distinct provider? I'm curious how you ran into this. > > You might know this already but zip provider ships as a demo provider > (source code is the demo directory) so it might be easy for you to test your > patch and also see if there are any other issues. I think it would be useful > to know if there are any other issues. I tested the updated method with the demo provider (I changed the scheme and the package to avoid conflicts) and it works. I did a quick code review and that was the only reference to file that I could find. Having that said I'm a bit confused by the JarFileSystemProvider. It's a subclass of ZipFileSystemProvider but has the scheme and is not referenced anywhere. Cheers Philippe From philippe.marschall at gmail.com Sun Dec 9 07:08:59 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sun, 9 Dec 2012 16:08:59 +0100 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> Message-ID: On Sat, Dec 8, 2012 at 9:18 PM, Michael Hall wrote: > It's a demo. > > Couldn't you just temporarily put your own ZipFileSystem in classpath some > place before the default version jar? Well, since zipfs.jar is part of the JRE that would probably have go to do endorsed/ not the nicest place to be. > With something like? > > In com.sun.nio.zipfs.ZipFileSystem > > // Creates a new empty temporary file in the same directory as the > // specified file. A variant of File.createTempFile. > private Path createTempFileInSameDirectoryAs(Path path) > throws IOException > { > Path parent = path.toAbsolutePath().getParent(); > Path tmpPath = Files.createTempFile(dir,"zipfstmp", null); > tmppaths.add(tmpPath); > return tmpPath; > } > > Assumes it'll use the correct FileSystem as the parameter's Path all the way > through, I haven't tested it at all. > Not sure if there are any complications with a com.sun class. You could > change the demo package. > > Are you just trying this out or do you intend to use the demo code in > something production? The plan is to use it in testing, like an in-memory database (JavaDB, ?). Especially interesting would be that you can simulate a Linux/Windows/Mac file system on a developer workstation without having to run the tests on a slave. It would also be cool if you could initialize a file system from a ZIP file and drop the contents of the file system into a ZIP file for analysis if the test fails. And sometimes you just want to create an in-memory zip, eg. in a servlet. Cheers Philippe From mik3hall at gmail.com Sun Dec 9 08:31:42 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 9 Dec 2012 10:31:42 -0600 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> Message-ID: <78D25392-1DFD-44AF-B537-0E678CF244D7@gmail.com> Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter On Dec 9, 2012, at 9:08 AM, Philippe Marschall wrote: > On Sat, Dec 8, 2012 at 9:18 PM, Michael Hall wrote: >> It's a demo. >> >> Couldn't you just temporarily put your own ZipFileSystem in classpath some >> place before the default version jar? > > Well, since zipfs.jar is part of the JRE that would probably have go > to do endorsed/ not the nicest place to be. Not familiar with the licensing concerns. Seems something that would be easy enough to work around. >> >> >> Are you just trying this out or do you intend to use the demo code in >> something production? > > The plan is to use it in testing, like an in-memory database (JavaDB, > ?). Especially interesting would be that you can simulate a > Linux/Windows/Mac file system on a developer workstation without > having to run the tests on a slave. It would also be cool if you could > initialize a file system from a ZIP file and drop the contents of the > file system into a ZIP file for analysis if the test fails. And > sometimes you just want to create an in-memory zip, eg. in a servlet. Again, as long as it was test I would think the licensing would be less of a concern but could be wrong. I didn't mean to suggest there was anything wrong with the code as far as it being demo but I would think in some companies there could be concerns with support for demo code as opposed to core java. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121209/eb2ae796/attachment.html From xueming.shen at oracle.com Sun Dec 9 09:31:14 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 09 Dec 2012 09:31:14 -0800 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> Message-ID: <50C4CAE2.6070605@oracle.com> On 12/9/12 7:08 AM, Philippe Marschall wrote: > On Sat, Dec 8, 2012 at 9:18 PM, Michael Hall wrote: >> It's a demo. >> >> Couldn't you just temporarily put your own ZipFileSystem in classpath some >> place before the default version jar? > Well, since zipfs.jar is part of the JRE that would probably have go > to do endorsed/ not the nicest place to be. > > The bug will be investigated and fixed, probably together with other reported zfs bugs/rfes. Just too busy these days on another JDK8 project for now. -Sherman From philippe.marschall at gmail.com Sun Dec 9 10:36:34 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sun, 9 Dec 2012 19:36:34 +0100 Subject: Zip file system provider only works with default file system In-Reply-To: <50C4CAE2.6070605@oracle.com> References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> <50C4CAE2.6070605@oracle.com> Message-ID: On Sun, Dec 9, 2012 at 6:31 PM, Xueming Shen wrote: > On 12/9/12 7:08 AM, Philippe Marschall wrote: >> >> On Sat, Dec 8, 2012 at 9:18 PM, Michael Hall wrote: >>> >>> It's a demo. >>> >>> Couldn't you just temporarily put your own ZipFileSystem in classpath >>> some >>> place before the default version jar? >> >> Well, since zipfs.jar is part of the JRE that would probably have go >> to do endorsed/ not the nicest place to be. >> >> > The bug will be investigated and fixed, probably together with other > reported zfs bugs/rfes. Just > too busy these days on another JDK8 project for now. Is there a way I can help? Submitting a bug/patch/pull request? Cheers Philippe From Alan.Bateman at oracle.com Sun Dec 9 11:31:33 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 09 Dec 2012 19:31:33 +0000 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> <50C4CAE2.6070605@oracle.com> Message-ID: <50C4E715.6030606@oracle.com> On 09/12/2012 18:36, Philippe Marschall wrote: > : > Is there a way I can help? Submitting a bug/patch/pull request? > > Cheers > Philippe I think it would be great if you could submit a patch. Here's the "How to contribute" page: http://openjdk.java.net/contribute/ I checked the OCA signatories list [1] and you are listed so this make things easier. I've created a bug to track the issue: 8004789: (zipfs) zip provider doesn't work correctly with file systems providers rather than the default -Alan [1] http://www.oracle.com/technetwork/community/oca-486395.html From Alan.Bateman at oracle.com Sun Dec 9 11:33:50 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 09 Dec 2012 19:33:50 +0000 Subject: Zip file system provider only works with default file system In-Reply-To: <50C39AE4.1070308@oracle.com> References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> Message-ID: <50C4E79E.3010105@oracle.com> On 08/12/2012 19:54, Xueming Shen wrote: > This is why it's a bug:-) The temp file should be on your memory file > system, not > the default file system (java.io.File only knows about the default > one). So we > probably should not use the java.io.File for the temporary file, if we > are not on > the default file system. > > -Sherman I took a quick look at this and I think the temporary file can either if co-located with the zip file (as per the current implementation) or alternatively it can be a temporary file on the default file system. For the former then it creates using Files.createTempFile as per the discussion here. For the latter then it would require using the temporary directory, in which case it would be okay to use java.io.File, just not consistent. -Alan From Alan.Bateman at oracle.com Sun Dec 9 11:38:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 09 Dec 2012 19:38:42 +0000 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> Message-ID: <50C4E8C2.1050907@oracle.com> On 09/12/2012 14:54, Philippe Marschall wrote: > : > Having that said I'm a bit confused by the JarFileSystemProvider. It's > a subclass of ZipFileSystemProvider but has the scheme and is not > referenced anywhere. Sherman might remember, I suspect it's left over from easy versions that support both the "zip" and "jar" schemes. -Alan. From Alan.Bateman at oracle.com Sun Dec 9 11:49:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 09 Dec 2012 19:49:08 +0000 Subject: Zip file system provider only works with default file system In-Reply-To: References: <50C31BE5.5080304@oracle.com> <50C395F3.2050200@oracle.com> <50C39AE4.1070308@oracle.com> Message-ID: <50C4EB34.2050800@oracle.com> On 09/12/2012 15:08, Philippe Marschall wrote: > : > Well, since zipfs.jar is part of the JRE that would probably have go > to do endorsed/ not the nicest place to be. > > Just to explain, the reason it's in the extensions directory is so that the zip providers work "out of the box". It doubles up as a demo provider, with source code, to help those looks to develop their own file system providers. -Alan From philippe.marschall at gmail.com Sun Dec 9 14:08:55 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sun, 9 Dec 2012 23:08:55 +0100 Subject: [PATCH] 8004789 : (zipfs) zip provider doesn't work correctly with file systems providers rather than the default Message-ID: Hi As discussed previously [1] here are the patches against JDK 7 and 8 to make the ZipFileSystem provider use Files#createTempFile instead of File#createTempFile. This causes the temporary file to be created on the same file system as the ZIP file resides on. This makes it possible to run the zipfs provider on a file system other than the default one. This patch does not include any tests but I also could not find any existing ones. If somebody wants tests I'd be happy to supply them once instructed who to do them and where to put them. I did already sign the OCA (for the BTrace project) [3]. [1] http://mail.openjdk.java.net/pipermail/nio-dev/2012-December/002041.html [2] http://bugs.sun.com/view_bug.do?bug_id=8004789 [3] http://www.oracle.com/technetwork/community/oca-486395.html#m Cheers Philippe -------------- next part -------------- A non-text attachment was scrubbed... Name: 8004789-jdk7.patch Type: application/octet-stream Size: 2150 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121209/5c680414/8004789-jdk7.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: 8004789-jdk8.patch Type: application/octet-stream Size: 2150 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121209/5c680414/8004789-jdk8.patch From Alan.Bateman at oracle.com Mon Dec 10 03:06:10 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2012 11:06:10 +0000 Subject: [PATCH] 8004789 : (zipfs) zip provider doesn't work correctly with file systems providers rather than the default In-Reply-To: References: Message-ID: <50C5C222.7030407@oracle.com> On 09/12/2012 22:08, Philippe Marschall wrote: > Hi > > As discussed previously [1] here are the patches against JDK 7 and 8 > to make the ZipFileSystem provider use Files#createTempFile instead of > File#createTempFile. This causes the temporary file to be created on > the same file system as the ZIP file resides on. This makes it > possible to run the zipfs provider on a file system other than the > default one. > > This patch does not include any tests but I also could not find any > existing ones. If somebody wants tests I'd be happy to supply them > once instructed who to do them and where to put them. > Thanks for the patch, it looks okay to me. I see that toAbsolutePath is used but that isn't actually required. Sherman - do you want to sponsor this? The tests for the zip provider are in jdk/test/demo/zipfs. As the scenario requires three file system providers to demonstrate then it would be a lot of work to create a test case, in which case I think it's okay to let it out for this one. -Alan From philippe.marschall at gmail.com Mon Dec 10 11:02:23 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Mon, 10 Dec 2012 20:02:23 +0100 Subject: [PATCH] 8004789 : (zipfs) zip provider doesn't work correctly with file systems providers rather than the default In-Reply-To: <50C5C222.7030407@oracle.com> References: <50C5C222.7030407@oracle.com> Message-ID: On Mon, Dec 10, 2012 at 12:06 PM, Alan Bateman wrote: > On 09/12/2012 22:08, Philippe Marschall wrote: >> >> Hi >> >> As discussed previously [1] here are the patches against JDK 7 and 8 >> to make the ZipFileSystem provider use Files#createTempFile instead of >> File#createTempFile. This causes the temporary file to be created on >> the same file system as the ZIP file resides on. This makes it >> possible to run the zipfs provider on a file system other than the >> default one. >> >> This patch does not include any tests but I also could not find any >> existing ones. If somebody wants tests I'd be happy to supply them >> once instructed who to do them and where to put them. >> > Thanks for the patch, it looks okay to me. I see that toAbsolutePath is used > but that isn't actually required. Sherman - do you want to sponsor this? #toAbsolutePath() is in for two reasons. First it's there in the existing code and I wanted to change as little as possible to keep the side effects as small as possible. Second I believe it would be theoretically possible (and spec compliant) to create a zipfs on a relative path. In such a case #getParent() may return null. For that to happen a file system provider would have to support creating relative paths from an URI. I don't recall any part of the spec that would forbid this. Path#toUri() describes the behaviour of the default provider and says all other providers can do what they want. However you're certainly more familiar with the spec than I am. Cheers Philippe From xueming.shen at oracle.com Mon Dec 10 11:10:11 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 10 Dec 2012 11:10:11 -0800 Subject: [PATCH] 8004789 : (zipfs) zip provider doesn't work correctly with file systems providers rather than the default In-Reply-To: <50C5C222.7030407@oracle.com> References: <50C5C222.7030407@oracle.com> Message-ID: <50C63393.50104@oracle.com> On 12/10/2012 03:06 AM, Alan Bateman wrote: > On 09/12/2012 22:08, Philippe Marschall wrote: >> Hi >> >> As discussed previously [1] here are the patches against JDK 7 and 8 >> to make the ZipFileSystem provider use Files#createTempFile instead of >> File#createTempFile. This causes the temporary file to be created on >> the same file system as the ZIP file resides on. This makes it >> possible to run the zipfs provider on a file system other than the >> default one. >> >> This patch does not include any tests but I also could not find any >> existing ones. If somebody wants tests I'd be happy to supply them >> once instructed who to do them and where to put them. >> > Thanks for the patch, it looks okay to me. I see that toAbsolutePath is used but that isn't actually required. Sherman - do you want to sponsor this? > > The tests for the zip provider are in jdk/test/demo/zipfs. As the scenario requires three file system providers to demonstrate then it would be a lot of work to create a test case, in which case I think it's okay to let it out for this one. > > -Alan > I will sponsor the patch. -Sherman From dan.xu at oracle.com Mon Dec 10 14:28:23 2012 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 10 Dec 2012 14:28:23 -0800 Subject: Review Request : JDK-8002306,(se) Selector.open fails if invoked with thread interrupt status set [win] Message-ID: <50C66207.9050508@oracle.com> Hi folks, Please help review the fix for JDK-8002306, Selector.open fails if invoked with thread interrupt status set [win], at http://cr.openjdk.java.net/~dxu/8002306/webrev/ On windows, we establish loopback socket connections every time a selector is opened. But the connect operation will fail and throw out ClosedByInterruptException if its current thread is interrupted. In order to open a selector on an interrupted thread successfully, the fix clears the interrupt status, establish socket connections, and reset the status to interrupt afterwards to work around the restrictions. Thanks! -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121210/ec063a48/attachment.html From david.lloyd at redhat.com Mon Dec 10 14:51:38 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 10 Dec 2012 16:51:38 -0600 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50C66207.9050508@oracle.com> References: <50C66207.9050508@oracle.com> Message-ID: <50C6677A.5020701@redhat.com> On 12/10/2012 04:28 PM, Dan Xu wrote: > Hi folks, > > Please help review the fix for JDK-8002306, Selector.open fails if > invoked with thread interrupt status set [win], at > http://cr.openjdk.java.net/~dxu/8002306/webrev/ > > > On windows, we establish loopback socket connections every time a > selector is opened. But the connect operation will fail and throw out > ClosedByInterruptException if its current thread is interrupted. In > order to open a selector on an interrupted thread successfully, the fix > clears the interrupt status, establish socket connections, and reset the > status to interrupt afterwards to work around the restrictions. Thanks! There will still be a race where the thread interrupt status could be set after it was cleared but before the selector is created. I think there are probably only two viable options here: 1. Treat the current behavior as "correct": you cannot open a selector when the current thread is interrupted. 2. Rewrite the selector open operation such that it creates the socket without respecting the state of the interrupted flag. -- - DML From dan.xu at oracle.com Mon Dec 10 16:24:25 2012 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 10 Dec 2012 16:24:25 -0800 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50C6677A.5020701@redhat.com> References: <50C66207.9050508@oracle.com> <50C6677A.5020701@redhat.com> Message-ID: <50C67D39.4040201@oracle.com> On 12/10/2012 02:51 PM, David M. Lloyd wrote: > On 12/10/2012 04:28 PM, Dan Xu wrote: >> Hi folks, >> >> Please help review the fix for JDK-8002306, Selector.open fails if >> invoked with thread interrupt status set [win], at >> http://cr.openjdk.java.net/~dxu/8002306/webrev/ >> >> >> On windows, we establish loopback socket connections every time a >> selector is opened. But the connect operation will fail and throw out >> ClosedByInterruptException if its current thread is interrupted. In >> order to open a selector on an interrupted thread successfully, the fix >> clears the interrupt status, establish socket connections, and reset the >> status to interrupt afterwards to work around the restrictions. Thanks! > > There will still be a race where the thread interrupt status could be > set after it was cleared but before the selector is created. > > I think there are probably only two viable options here: > > 1. Treat the current behavior as "correct": you cannot open a selector > when the current thread is interrupted. > 2. Rewrite the selector open operation such that it creates the socket > without respecting the state of the interrupted flag. > The issue of this bug is not only the exception, but also the same code has different behaviour on Windows in comparison with other platforms. In my understanding, it should deliver the same result on all supported platforms. I briefed the race issue to Alan in the weekend. And in order to fix it, I need more support from the lower layer, which needs to extend the scope of the fix. -Dan From Alan.Bateman at oracle.com Tue Dec 11 02:18:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Dec 2012 10:18:08 +0000 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50C6677A.5020701@redhat.com> References: <50C66207.9050508@oracle.com> <50C6677A.5020701@redhat.com> Message-ID: <50C70860.4040702@oracle.com> On 10/12/2012 22:51, David M. Lloyd wrote: > > There will still be a race where the thread interrupt status could be > set after it was cleared but before the selector is created. If the interrupt status is set before the loopback connection is established then it will just retry, if the interrupt status is setup after the loopback connection is established then it doesn't matter. There is of course the possibility that something is calling interrupt continuously, in which case the Pipe.open might just end failing because of connections in TIME_WAIT but that shouldn't be too common. > > I think there are probably only two viable options here: > > 1. Treat the current behavior as "correct": you cannot open a selector > when the current thread is interrupted. I don't think we need to go down that road, I've no doubt it would cause problems. > 2. Rewrite the selector open operation such that it creates the socket > without respecting the state of the interrupted flag. > It's implementation specific that Pipe is implemented on Windows with a socket connection (had to be done that way because Windows pipes can't be multiplexed with sockets). It would be possible to change the Pipe implementation to uses the low-level APIs, not sure if it's worth it. -Alan From zhouyx at linux.vnet.ibm.com Tue Dec 11 04:13:36 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Tue, 11 Dec 2012 20:13:36 +0800 Subject: Should java/nio/channels/spi/AbstractInterruptibleChannel.java#isOpen be synchronized ? In-Reply-To: <50BF1DA1.2050306@oracle.com> References: <50BE04FC.50000@oracle.com> <50BE0ADB.8090903@oracle.com> <50BF1DA1.2050306@oracle.com> Message-ID: Hi, This is the detail problem, there is a small time window in which a 3 threads race makes select() always return 0 without blocking. I wrote a testcase(http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/) but it needs to modify the lib to reproduce, because the time windows is small. The reproduce scenario is described in follow, use Tx for thread x: 1. T1 (the user code) is selecting a channel(suppose C), it just returns from native select function, and niolib select method is checking if the returned channel is interested in the event, then 2 happens; 2. T2 is closing channel C, it just set the open variable to false but not yet closed the channel actually, and then 3 happens; 3. T3 set the interedOps of the channel to 0. // 0 means the channel is not interested in anything, the channel will be put into cancel list normally. In this senario, T1 returns from select, and return 0 which means no channel is selected(because the channel C returned from native invocation has nothing insterested in, it is not returned to application). Then T1 goes to invoke select again(usually in a loop, this is how select is designed to be used). In normal case, select method checks if any channels those should be cancelled and remove them from the set to be selected. Then, goes to native select function. The problem is: select method first checks if the channel is closed, if it is closed, select method doesn't put it into cancel list. In above senario, channel C is in close state, but not closed indeed, and setInteredOps to 0(which means cancel). So select method doesn't put C into cancel list(due to the problem) which means the native select set still contains channel C . So the native select always return C and nio select always return 0. Until the channel is finally closed. The testcase: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ A working fix: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/ Please have a look. On Wed, Dec 5, 2012 at 6:10 PM, Alan Bateman wrote: > On 05/12/2012 02:47, Sean Chou wrote: > > A small problem I'm still checking. So the closeLock is just to make sure > the channel is closed only once, is that right? > > This is how close is specified: > > "If this channel is already closed then invoking this method has no > effect. > > This method may be invoked at any time. If some other thread has already > invoked it, however, then another invocation will block until the first > invocation is complete, after which it will return without effect." > > -Alan. > > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121211/215103cd/attachment.html From zhouyx at linux.vnet.ibm.com Tue Dec 11 04:30:42 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Tue, 11 Dec 2012 20:30:42 +0800 Subject: Should java/nio/channels/spi/AbstractInterruptibleChannel.java#isOpen be synchronized ? In-Reply-To: References: <50BE04FC.50000@oracle.com> <50BE0ADB.8090903@oracle.com> <50BF1DA1.2050306@oracle.com> Message-ID: Forget to say, the bug appears on linux, and the fix is for linux. The testcase doesn't reproduce on windows. On Tue, Dec 11, 2012 at 8:13 PM, Sean Chou wrote: > Hi, > > This is the detail problem, there is a small time window in which a 3 > threads race makes select() always return 0 without blocking. > > I wrote a testcase(http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/) > but it needs to modify the lib to reproduce, because the time windows is > small. > > The reproduce scenario is described in follow, use Tx for thread x: > > 1. T1 (the user code) is selecting a channel(suppose C), it just returns > from native select function, and niolib select method is checking if the > returned channel is interested in the event, then 2 happens; > 2. T2 is closing channel C, it just set the open variable to false but not > yet closed the channel actually, and then 3 happens; > 3. T3 set the interedOps of the channel to 0. // 0 means the channel is > not interested in anything, the channel will be put into cancel list > normally. > > In this senario, T1 returns from select, and return 0 which means no > channel is selected(because the channel C returned from native invocation > has nothing insterested in, it is not returned to application). Then T1 > goes to invoke select again(usually in a loop, this is how select is > designed to be used). In normal case, select method checks if any channels > those should be cancelled and remove them from the set to be selected. > Then, goes to native select function. > > The problem is: select method first checks if the channel is closed, if it > is closed, select method doesn't put it into cancel list. > > In above senario, channel C is in close state, but not closed indeed, and > setInteredOps to 0(which means cancel). So select method doesn't put C into > cancel list(due to the problem) which means the native select set still > contains channel C . So the native select always return C and nio select > always return 0. Until the channel is finally closed. > > > The testcase: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ > > A working fix: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/ > > > Please have a look. > > > On Wed, Dec 5, 2012 at 6:10 PM, Alan Bateman wrote: > >> On 05/12/2012 02:47, Sean Chou wrote: >> >> A small problem I'm still checking. So the closeLock is just to make sure >> the channel is closed only once, is that right? >> >> This is how close is specified: >> >> "If this channel is already closed then invoking this method has no >> effect. >> >> This method may be invoked at any time. If some other thread has already >> invoked it, however, then another invocation will block until the first >> invocation is complete, after which it will return without effect." >> >> -Alan. >> >> > > > -- > Best Regards, > Sean Chou > > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121211/a430540f/attachment-0001.html From Alan.Bateman at oracle.com Tue Dec 11 10:05:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Dec 2012 18:05:27 +0000 Subject: [PATCH] 8004789 : (zipfs) zip provider doesn't work correctly with file systems providers rather than the default In-Reply-To: References: <50C5C222.7030407@oracle.com> Message-ID: <50C775E7.4090306@oracle.com> On 10/12/2012 19:02, Philippe Marschall wrote: > : > > #toAbsolutePath() is in for two reasons. First it's there in the > existing code and I wanted to change as little as possible to keep the > side effects as small as possible. Second I believe it would be > theoretically possible (and spec compliant) to create a zipfs on a > relative path. In such a case #getParent() may return null. For that > to happen a file system provider would have to support creating > relative paths from an URI. I don't recall any part of the spec that > would forbid this. Path#toUri() describes the behaviour of the default > provider and says all other providers can do what they want. However > you're certainly more familiar with the spec than I am. > The toAbsolutePath is mostly harmless here, but not strictly required because all the Files methods accept relative paths. -Alan. From philippe.marschall at gmail.com Tue Dec 11 13:00:58 2012 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 11 Dec 2012 22:00:58 +0100 Subject: [PATCH] 8004789 : (zipfs) zip provider doesn't work correctly with file systems providers rather than the default In-Reply-To: <50C775E7.4090306@oracle.com> References: <50C5C222.7030407@oracle.com> <50C775E7.4090306@oracle.com> Message-ID: On Tue, Dec 11, 2012 at 7:05 PM, Alan Bateman wrote: > On 10/12/2012 19:02, Philippe Marschall wrote: >> >> : >> >> #toAbsolutePath() is in for two reasons. First it's there in the >> existing code and I wanted to change as little as possible to keep the >> side effects as small as possible. Second I believe it would be >> theoretically possible (and spec compliant) to create a zipfs on a >> relative path. In such a case #getParent() may return null. For that >> to happen a file system provider would have to support creating >> relative paths from an URI. I don't recall any part of the spec that >> would forbid this. Path#toUri() describes the behaviour of the default >> provider and says all other providers can do what they want. However >> you're certainly more familiar with the spec than I am. >> > The toAbsolutePath is mostly harmless here, but not strictly required > because all the Files methods accept relative paths. Right, but I was mostly concerned with null. Files#createTempFile does not accept null as a path. As we want to create the temp file in the parent directory of the zip file. So we use: Files.createTempFile(path.getParent(), ?, ?) however when path is relative then #getParent can return null so we would end up doing Files.createTempFile(null, ?, ?) which would throw a NullPointerException. #createTempFileInSameDirectoryAs has some fallback to do deal with null parents however that relies on ".". Path#normalize() mentions that some file systems support "." but does not require them to do so. So doing #toAbsolutePath() before the fallback seems more robust. Cheers Philippe From Alan.Bateman at oracle.com Wed Dec 12 04:57:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2012 12:57:17 +0000 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50C66207.9050508@oracle.com> References: <50C66207.9050508@oracle.com> Message-ID: <50C87F2D.4050007@oracle.com> On 10/12/2012 22:28, Dan Xu wrote: > Hi folks, > > Please help review the fix for JDK-8002306, Selector.open fails if > invoked with thread interrupt status set [win], at > http://cr.openjdk.java.net/~dxu/8002306/webrev/ > > > On windows, we establish loopback socket connections every time a > selector is opened. But the connect operation will fail and throw out > ClosedByInterruptException if its current thread is interrupted. In > order to open a selector on an interrupted thread successfully, the > fix clears the interrupt status, establish socket connections, and > reset the status to interrupt afterwards to work around the > restrictions. Thanks! > > -Dan I looked at the proposed change, but I think it could be a bit simpler (meaning no null or isConnected checks) if we simple start over when ClosedByInterrupt is thrown. So if open(sa) fails then ssc.close and retry, if accept() fails then sc1.close ssc.close and retry. I think that would make it easier to verify too. I'm interested in David Lloyd's comment about a timing issue as he may be seeing something that I don't see. On the test then I don't think @library is needed. Also would be good if this test didn't have to run in othervm mode. If the test closes the Selector then I think it should be good to run in agent VM mode (meaning it can run in an existing VM, doesn't need to spin up a new VM for the test). Also what would you think about beefing it up so that pounds a thread calling Pipe.open with Thread.interrupt, I think this is the only way that this can be properly tested. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121212/1579fc01/attachment.html From zhouyx at linux.vnet.ibm.com Mon Dec 17 00:56:44 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Mon, 17 Dec 2012 16:56:44 +0800 Subject: A race problem about select in a small time window Message-ID: Hello , This is the detail problem, there is a small time window in which a 3 threads race makes select() always return 0 without blocking. I wrote a testcase(http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/) which needs to modify the lib code to reproduce, because the time windows is small. The reproduce scenario is described in follow, use Tx for thread x: 1. T1 (the user code) is selecting a channel(suppose C), it just returns from native select function, and niolib select method is checking if the returned channel is interested in the event, then 2 happens; 2. T2 is closing channel C, it just set the open variable to false but not yet closed the channel actually, and then 3 happens; 3. T3 set the interedOps of the channel to 0. // 0 means the channel is not interested in anything, the channel will be put into cancel list normally. In this senario, T1 returns from select, and return 0 which means no channel is selected(because the channel C returned from native invocation has nothing insterested in, it is not returned to application). Then T1 goes to invoke select again(usually in a loop, this is how select is designed to be used). In normal case, select method checks if any channels those should be cancelled and remove them from the set to be selected. Then, goes to native select function. The problem is: select method first checks if the channel is closed, if it is closed, select method doesn't put it into cancel list. In above senario, channel C is in close state, but not closed indeed, and setInteredOps to 0(which means cancel). So select method doesn't put C into cancel list(due to the problem) which means the native select set still contains channel C . So the native select always return C and nio select always return 0. Until the channel is finally closed. The testcase: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ A working fix: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/ Please have a look. On Wed, Dec 5, 2012 at 6:10 PM, Alan Bateman wrote: > On 05/12/2012 02:47, Sean Chou wrote: > > A small problem I'm still checking. So the closeLock is just to make sure > the channel is closed only once, is that right? > > This is how close is specified: > > "If this channel is already closed then invoking this method has no > effect. > > This method may be invoked at any time. If some other thread has already > invoked it, however, then another invocation will block until the first > invocation is complete, after which it will return without effect." > > -Alan. > > -- Best Regards, Sean Chou -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121217/640d3644/attachment.html From charis.charitsis at oracle.com Mon Dec 17 21:55:40 2012 From: charis.charitsis at oracle.com (charis) Date: Mon, 17 Dec 2012 21:55:40 -0800 (PST) Subject: InetAddress.getAllByName()/getByName() fails to resolve IPv6 via ssh Message-ID: <1355810140894-7574957.post@n2.nabble.com> I am facing the following issue: Say there is a simple standlone code Test.java which just calls InetAddress.getAllByName() : * import java.net.Inet4Address; import java.net.Inet6Address; import java.net.InetAddress; import java.net.UnknownHostException; public class TestNameResolution { public static void main(String args[]) { String name = args[0]; System.out.println("Trying to resolve name \"" + name + "\" to IP addresses"); try { InetAddress[] addresses = InetAddress.getAllByName(name); for (int i = 0; i < addresses.length; i++) { if (addresses[i] instanceof Inet4Address) { System.out.println("IPv4 address -->" + addresses[i].getHostAddress()); } else if (addresses[i] instanceof Inet6Address) { System.out.println("IPv6 address -->" + addresses[i].getHostAddress()); } } } catch (UnknownHostException uhe) { System.out.println("Cannot resolve name \"" + name + "\""); } } } * I run this via a simple single-line script 'run': * java -classpath TestNameResolution * When try this locally it resolves the name to its IPv6 address as expected. However, when from a different machine to execute this via ssh (i.e., ssh ) I often get the following output: / Trying to resolve name "" to IP addresses Cannot resolve name "" java.net.UnknownHostException: at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849) at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1202) at java.net.InetAddress.getAllByName0(InetAddress.java:1153) at java.net.InetAddress.getAllByName(InetAddress.java:1083) at java.net.InetAddress.getAllByName(InetAddress.java:1019) at TestNameResolution.main(TestNameResolution.java:14 / Note: - I tried the java command that invokes the standalone also with i) '-Djava.net.preferIPv6Stack=true' , ii) and '-Djava.net.preferIPv6Addresses=true' and iii) with both of them at the same time. Still, the output is the same - The same standalone succeeds in resolving a name which maps to IPv4 giving the same (correct) output on the local and the remote node (where the ssh is initiated) Java environment details: $ java -version java version "1.6.0_37" Java(TM) SE Runtime Environment (build 1.6.0_37-b06) Is there any known issue with IPv6 name resolution via ssh? Any ideas what may be causing this? -- View this message in context: http://nio-dev.3157472.n2.nabble.com/InetAddress-getAllByName-getByName-fails-to-resolve-IPv6-via-ssh-tp7574957.html Sent from the nio-dev mailing list archive at Nabble.com. From dan.xu at oracle.com Tue Dec 18 11:32:01 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 18 Dec 2012 11:32:01 -0800 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50C87F2D.4050007@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> Message-ID: <50D0C4B1.40807@oracle.com> On 12/12/2012 04:57 AM, Alan Bateman wrote: > On 10/12/2012 22:28, Dan Xu wrote: >> Hi folks, >> >> Please help review the fix for JDK-8002306, Selector.open fails if >> invoked with thread interrupt status set [win], at >> http://cr.openjdk.java.net/~dxu/8002306/webrev/ >> >> >> On windows, we establish loopback socket connections every time a >> selector is opened. But the connect operation will fail and throw out >> ClosedByInterruptException if its current thread is interrupted. In >> order to open a selector on an interrupted thread successfully, the >> fix clears the interrupt status, establish socket connections, and >> reset the status to interrupt afterwards to work around the >> restrictions. Thanks! >> >> -Dan > I looked at the proposed change, but I think it could be a bit simpler > (meaning no null or isConnected checks) if we simple start over when > ClosedByInterrupt is thrown. So if open(sa) fails then ssc.close and > retry, if accept() fails then sc1.close ssc.close and retry. I think > that would make it easier to verify too. I'm interested in David > Lloyd's comment about a timing issue as he may be seeing something > that I don't see. > > On the test then I don't think @library is needed. Also would be good > if this test didn't have to run in othervm mode. If the test closes > the Selector then I think it should be good to run in agent VM mode > (meaning it can run in an existing VM, doesn't need to spin up a new > VM for the test). Also what would you think about beefing it up so > that pounds a thread calling Pipe.open with Thread.interrupt, I think > this is the only way that this can be properly tested. > > -Alan I have updated my fix at, http://cr.openjdk.java.net/~dxu/8002306/webrev.01/ . It removes checks of null or isConnected, and also addresses a potential race situation by using an uninterruptible thread to establish the loopback connections, which is the last resort to solve the connection failures. In addition, the test is also updated to test the pipe directly. Please review the new changes. Thanks! -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121218/564d91d6/attachment.html From Alan.Bateman at oracle.com Tue Dec 18 13:17:55 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Dec 2012 21:17:55 +0000 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50D0C4B1.40807@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> Message-ID: <50D0DD83.3000705@oracle.com> On 18/12/2012 19:32, Dan Xu wrote: > : > > I have updated my fix at, > http://cr.openjdk.java.net/~dxu/8002306/webrev.01/ > . > > It removes checks of null or isConnected, and also addresses a > potential race situation by using an uninterruptible thread to > establish the loopback connections, which is the last resort to solve > the connection failures. In addition, the test is also updated to test > the pipe directly. Please review the new changes. Thanks! > > -Dan I think the approach is good but I'd prefer if we didn't duplicate the code to establish the loopback connection. If you could put this into own class (that implements Runnable) then you could invoke it directly first, and if that is interrupted then the background thread can invoke it from its run method. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121218/87f744b6/attachment.html From dan.xu at oracle.com Wed Dec 19 12:05:51 2012 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 19 Dec 2012 12:05:51 -0800 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50D0DD83.3000705@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> Message-ID: <50D21E1F.9000607@oracle.com> Hi Alan, Your suggestion makes the code much leaner. I have updated the fix at, http://cr.openjdk.java.net/~dxu/8002306/webrev.02/ Please help review it. Thanks! -Dan On 12/18/2012 01:17 PM, Alan Bateman wrote: > On 18/12/2012 19:32, Dan Xu wrote: >> : >> >> I have updated my fix at, >> http://cr.openjdk.java.net/~dxu/8002306/webrev.01/ >> . >> >> It removes checks of null or isConnected, and also addresses a >> potential race situation by using an uninterruptible thread to >> establish the loopback connections, which is the last resort to solve >> the connection failures. In addition, the test is also updated to >> test the pipe directly. Please review the new changes. Thanks! >> >> -Dan > I think the approach is good but I'd prefer if we didn't duplicate the > code to establish the loopback connection. If you could put this into > own class (that implements Runnable) then you could invoke it directly > first, and if that is interrupted then the background thread can > invoke it from its run method. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121219/f9bae87b/attachment.html From Alan.Bateman at oracle.com Fri Dec 21 07:54:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Dec 2012 15:54:34 +0000 Subject: A race problem about select in a small time window In-Reply-To: References: Message-ID: <50D4863A.5000109@oracle.com> I don't have cycles to look at this one (too much going on for M6) but Rob McKenna (cc'ed) might. On 17/12/2012 08:56, Sean Chou wrote: > Hello , > > This is the detail problem, there is a small time window in which a 3 > threads race makes select() always return 0 without blocking. > > I wrote a > testcase(http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ > ) which > needs to modify the lib code to reproduce, because the time windows is > small. > > The reproduce scenario is described in follow, use Tx for thread x: > > 1. T1 (the user code) is selecting a channel(suppose C), it just > returns from native select function, and niolib select method is > checking if the returned channel is interested in the event, then 2 > happens; > 2. T2 is closing channel C, it just set the open variable to false but > not yet closed the channel actually, and then 3 happens; > 3. T3 set the interedOps of the channel to 0. // 0 means the channel > is not interested in anything, the channel will be put into cancel > list normally. > > In this senario, T1 returns from select, and return 0 which means no > channel is selected(because the channel C returned from native > invocation has nothing insterested in, it is not returned to > application). Then T1 goes to invoke select again(usually in a loop, > this is how select is designed to be used). In normal case, select > method checks if any channels those should be cancelled and remove > them from the set to be selected. Then, goes to native select function. > > The problem is: select method first checks if the channel is closed, > if it is closed, select method doesn't put it into cancel list. > > In above senario, channel C is in close state, but not closed indeed, > and setInteredOps to 0(which means cancel). So select method doesn't > put C into cancel list(due to the problem) which means the native > select set still contains channel C . So the native select always > return C and nio select always return 0. Until the channel is finally > closed. > > > The testcase: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ > > > A working fix: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/ > > > > Please have a look. > > From Alan.Bateman at oracle.com Fri Dec 21 08:24:13 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Dec 2012 16:24:13 +0000 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50D21E1F.9000607@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> Message-ID: <50D48D2D.3030608@oracle.com> On 19/12/2012 20:05, Dan Xu wrote: > Hi Alan, > > Your suggestion makes the code much leaner. I have updated the fix at, > http://cr.openjdk.java.net/~dxu/8002306/webrev.02/ > > > Please help review it. Thanks! > > -Dan This is a lot cleaner. The read/write of ioe is subtle but as there is a Thread.join then I think it's okay. At line 101 then can source or sink be null if ioe is not null? If I read the test correctly then PipeTester waits until it is interrupted before it calls Pipe.open so this means it will never be asynchronous. For both PipeTester and and the main thread then I think it would be better to avoid the busy loop (the main thread can use Thread.join for example). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121221/4f4e2712/attachment.html