From gfz87 at hotmail.com Sun Sep 4 23:27:17 2011 From: gfz87 at hotmail.com (Gian Franco Zabarino) Date: Mon, 5 Sep 2011 06:27:17 +0000 Subject: AsynchronousCloseException when closing a channel Message-ID: Hi everybody, I found myself on a situation where I'm getting an AsynchronousCloseException, when calling to AsynchronousSocketChannel.close() method. I'm using JRE 1.7.0-b147, on Ubuntu server 64-bits. the call to the close method is made when an attempt for reading the channel is failed, inside the failed method of the read completionhandler. Is this normal behavior? This is the thread stack of the exception: java.nio.channels.AsynchronousCloseException at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finishRead(Unknown Source) at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finish(Unknown Source) at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implClose(Unknown Source) at sun.nio.ch.AsynchronousSocketChannelImpl.close(Unknown Source) at ... (project classes) Thank you for your time. Greetings Gian Franco Zabarino -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110905/f574d54e/attachment.html From zhouyx at linux.vnet.ibm.com Mon Sep 5 00:35:24 2011 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Mon, 5 Sep 2011 15:35:24 +0800 Subject: AsynchronousCloseException when closing a channel In-Reply-To: References: Message-ID: Hi Gian, Will you please give a simple testcase and the whole stack trace when throwing exception? It will be helpful. 2011/9/5 Gian Franco Zabarino > Hi everybody, I found myself on a situation where I'm getting an > AsynchronousCloseException, when calling to > AsynchronousSocketChannel.close() method. I'm using JRE 1.7.0-b147, on > Ubuntu server 64-bits. the call to the close method is made when an attempt > for reading the channel is failed, inside the failed method of the read > completionhandler. Is this normal behavior? This is the thread stack of the > exception: > > java.nio.channels.AsynchronousCloseException > at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finishRead(Unknown > Source) > at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finish(Unknown > Source) > at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implClose(Unknown > Source) > at sun.nio.ch.AsynchronousSocketChannelImpl.close(Unknown Source) > at ... (project classes) > > Thank you for your time. Greetings > > Gian Franco Zabarino > > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110905/322fb375/attachment.html From Alan.Bateman at oracle.com Mon Sep 5 01:11:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Sep 2011 09:11:19 +0100 Subject: AsynchronousCloseException when closing a channel In-Reply-To: References: Message-ID: <4E648427.9080605@oracle.com> Gian Franco Zabarino wrote: > Hi everybody, I found myself on a situation where I'm getting an > AsynchronousCloseException, when calling to > AsynchronousSocketChannel.close() method. I'm using JRE 1.7.0-b147, on > Ubuntu server 64-bits. the call to the close method is made when an > attempt for reading the channel is failed, inside the failed method of > the read completionhandler. Is this normal behavior? This is the > thread stack of the exception: > > java.nio.channels.AsynchronousCloseException > at > sun.nio.ch.UnixAsynchronousSocketChannelImpl.finishRead(Unknown Source) > at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finish(Unknown > Source) > at > sun.nio.ch.UnixAsynchronousSocketChannelImpl.implClose(Unknown Source) > at sun.nio.ch.AsynchronousSocketChannelImpl.close(Unknown Source) > at ... (project classes) > > Thank you for your time. Greetings > > Gian Franco Zabarino > If you close a channel with outstanding I/O operations then they are required to fail with an AsynchronousCloseException. So yes, this is normal but point taken that the stack trace is a bit confusing because it makes it look like the close is failing. It may be less confusing if we discard the stack trace (which is done in one or two places, but not consistently). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110905/bcc0225c/attachment.html From Alan.Bateman at oracle.com Sun Sep 18 01:25:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 18 Sep 2011 09:25:49 +0100 Subject: 7091935: (fs) Polling based WatchService not used on Linux Message-ID: <4E75AB0D.2060306@oracle.com> As folks will recall, we have 4 implementations of WatchService, one each for Solaris, Linux, and Windows and then a poor performing but portable implementation that polls the file system. Currently on Linux we build both the inotify and polling implementation but the polling implementation is never used at runtime. The attached patch just removes it from the make file so that it is no longer included on this platform. Thanks, Alan. diff --git a/make/java/nio/Makefile b/make/java/nio/Makefile --- a/make/java/nio/Makefile +++ b/make/java/nio/Makefile @@ -206,7 +206,6 @@ FILES_java += \ sun/nio/fs/LinuxUserDefinedFileAttributeView.java \ sun/nio/fs/LinuxNativeDispatcher.java \ sun/nio/fs/LinuxWatchService.java \ - sun/nio/fs/PollingWatchService.java \ sun/nio/fs/UnixChannelFactory.java \ sun/nio/fs/UnixCopyFile.java \ sun/nio/fs/UnixDirectoryStream.java \ From forax at univ-mlv.fr Sun Sep 18 03:01:21 2011 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 18 Sep 2011 12:01:21 +0200 Subject: 7091935: (fs) Polling based WatchService not used on Linux Message-ID: <91cywdl8fgxenism0gq559f4.1316340081384@email.android.com> Looks good. Remi Alan Bateman wrote: > >As folks will recall, we have 4 implementations of WatchService, one >each for Solaris, Linux, and Windows and then a poor performing but >portable implementation that polls the file system. Currently on Linux >we build both the inotify and polling implementation but the polling >implementation is never used at runtime. The attached patch just removes >it from the make file so that it is no longer included on this platform. > >Thanks, >Alan. > >diff --git a/make/java/nio/Makefile b/make/java/nio/Makefile >--- a/make/java/nio/Makefile >+++ b/make/java/nio/Makefile >@@ -206,7 +206,6 @@ FILES_java += \ > sun/nio/fs/LinuxUserDefinedFileAttributeView.java \ > sun/nio/fs/LinuxNativeDispatcher.java \ > sun/nio/fs/LinuxWatchService.java \ >- sun/nio/fs/PollingWatchService.java \ > sun/nio/fs/UnixChannelFactory.java \ > sun/nio/fs/UnixCopyFile.java \ > sun/nio/fs/UnixDirectoryStream.java \ > From mike.duigou at oracle.com Sun Sep 18 13:19:40 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 18 Sep 2011 13:19:40 -0700 Subject: 7091935: (fs) Polling based WatchService not used on Linux In-Reply-To: <4E75AB0D.2060306@oracle.com> References: <4E75AB0D.2060306@oracle.com> Message-ID: Looks fine. Mike On Sep 18 2011, at 01:25 , Alan Bateman wrote: > > As folks will recall, we have 4 implementations of WatchService, one each for Solaris, Linux, and Windows and then a poor performing but portable implementation that polls the file system. Currently on Linux we build both the inotify and polling implementation but the polling implementation is never used at runtime. The attached patch just removes it from the make file so that it is no longer included on this platform. > > Thanks, > Alan. > > diff --git a/make/java/nio/Makefile b/make/java/nio/Makefile > --- a/make/java/nio/Makefile > +++ b/make/java/nio/Makefile > @@ -206,7 +206,6 @@ FILES_java += \ > sun/nio/fs/LinuxUserDefinedFileAttributeView.java \ > sun/nio/fs/LinuxNativeDispatcher.java \ > sun/nio/fs/LinuxWatchService.java \ > - sun/nio/fs/PollingWatchService.java \ > sun/nio/fs/UnixChannelFactory.java \ > sun/nio/fs/UnixCopyFile.java \ > sun/nio/fs/UnixDirectoryStream.java \ > From Thomas.Salter at unisys.com Mon Sep 19 07:29:25 2011 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Mon, 19 Sep 2011 09:29:25 -0500 Subject: 7091935: (fs) Polling based WatchService not used on Linux In-Reply-To: <4E75AB0D.2060306@oracle.com> References: <4E75AB0D.2060306@oracle.com> Message-ID: <63D5DCACD1E9E34C89C8203C64F521C3FE5212D575@USEA-EXCH7.na.uis.unisys.com> Will it still be compiled at all, by Oracle builds? We're currently using it as a stop-gap solution until we can do a better performing implementation. I worry about the code continuing to compile cleanly (not to mention working) if it's not being compiled in the standard builds. Tom Salter -----Original Message----- From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman Sent: Sunday, September 18, 2011 4:26 AM To: nio-dev Subject: 7091935: (fs) Polling based WatchService not used on Linux As folks will recall, we have 4 implementations of WatchService, one each for Solaris, Linux, and Windows and then a poor performing but portable implementation that polls the file system. Currently on Linux we build both the inotify and polling implementation but the polling implementation is never used at runtime. The attached patch just removes it from the make file so that it is no longer included on this platform. Thanks, Alan. diff --git a/make/java/nio/Makefile b/make/java/nio/Makefile --- a/make/java/nio/Makefile +++ b/make/java/nio/Makefile @@ -206,7 +206,6 @@ FILES_java += \ sun/nio/fs/LinuxUserDefinedFileAttributeView.java \ sun/nio/fs/LinuxNativeDispatcher.java \ sun/nio/fs/LinuxWatchService.java \ - sun/nio/fs/PollingWatchService.java \ sun/nio/fs/UnixChannelFactory.java \ sun/nio/fs/UnixCopyFile.java \ sun/nio/fs/UnixDirectoryStream.java \ From Alan.Bateman at oracle.com Mon Sep 19 11:18:28 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Sep 2011 19:18:28 +0100 Subject: 7091935: (fs) Polling based WatchService not used on Linux In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C3FE5212D575@USEA-EXCH7.na.uis.unisys.com> References: <4E75AB0D.2060306@oracle.com> <63D5DCACD1E9E34C89C8203C64F521C3FE5212D575@USEA-EXCH7.na.uis.unisys.com> Message-ID: <4E778774.40804@oracle.com> Salter, Thomas A wrote: > Will it still be compiled at all, by Oracle builds? We're currently using it as a stop-gap solution until we can do a better performing implementation. I worry about the code continuing to compile cleanly (not to mention working) if it's not being compiled in the standard builds. > > Tom Salter > Yes, it's still built and used on Solaris 10 (but not Solaris 11). I believe it is also used in the BSD/Mac port. -Alan.