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