8202252: (aio) Closed AsynchronousSocketChannel keeps completion handler alive

Brian Burkhalter brian.burkhalter at oracle.com
Wed Jun 27 16:27:31 UTC 2018

On Jun 27, 2018, at 8:25 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> The updates to finishRead and finishWrite look okay. The change to set connectHandler to null needs more checking, I can't immediately say if this if right. Is this part of a series of patches?


> I assumed the Windows code would be changed, also the AsynchronousServerSocketChannel implementations.

The Windows code does not have this problem: it does not cache handler that I can see. The test passes on Windows without the source update.

> The test does this:
> System.gc();
> assertNull(ref.get());
> The more usual check is something like this:
> while (ref.get() != null) { Thread.sleep(20); }
> so that the test waits until the reference is cleared.

OK, will update.

> Is there a reason why the thread uses a custom channel group? I assume it can use the default channel group, would reduce the code a bit if you want.

There is for example this check

                attemptRead = invokeDirect || !port.isFixedThreadPool();

and if attemptRead is true then a direct read is attempted without the handler.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180627/12fb5a2e/attachment.html>

More information about the nio-dev mailing list