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: <SNT141-W58C1520ABB5DAF21C1A3FABB1D0@phx.gbl>


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: <SNT141-W58C1520ABB5DAF21C1A3FABB1D0@phx.gbl>
References: <SNT141-W58C1520ABB5DAF21C1A3FABB1D0@phx.gbl>
Message-ID: <CAOo=rxVd2iYgPrK+2NqyidvVSgxRp3_WfCRisiyrKtrP9__zRQ@mail.gmail.com>

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 <gfz87 at hotmail.com>

>  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: <SNT141-W58C1520ABB5DAF21C1A3FABB1D0@phx.gbl>
References: <SNT141-W58C1520ABB5DAF21C1A3FABB1D0@phx.gbl>
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 <Alan.Bateman at oracle.com> 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: <B5019812-B02C-4526-AFEC-0949B0E98D44@oracle.com>

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.