RFR[8246707]: '(sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel'
Conor Cleary
conor.cleary at oracle.com
Fri Jul 31 15:16:02 UTC 2020
Hi guys,
If you have a minute could you take a look at my new webrev for
JDK-8246707 '(sc) SocketChannel.read/write throws
AsynchronousCloseException on closed channel'?
I updated the revision to include ensureOpenAndConnected() checks for
blockingRead, blockingWriteFully and sendOutOfBandData before checking
the blocking mode. Also, a test to check that a ClosedChannelException
is thrown for read and write operations on a closed SocketChannel is now
included (ReadWriteAfterClose.java).
Thanks!
bug: https://bugs.openjdk.java.net/browse/JDK-8246707
webrev:
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.05/
On 16/07/2020 17:26, Alan Bateman wrote:
> On 16/07/2020 17:03, Conor Cleary wrote:
>>
>> Hi all,
>>
>> Could someone please take a look at my webrev for JDK-8246707 '(sc)
>> SocketChannel.read/write throws AsynchronousCloseException on closed
>> channel'?
>>
>> This fix addresses an issue where an AsynchronousCloseException was
>> being thrown instead of a ChannelClosedException when
>> SocketChannel.write() is called on a /closed/ SocketChannel.
>>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8246707
>> webrev:
>> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.02/
>>
> Thanks for this, this was an oversight when this code was refactored.
> It's not technically wrong to throw a sub-class of
> ChannelClosedException but AsynchronousCloseException could indeed be
> confusion. Are you planning to include a test? It may be that some of
> the existing tests to check that ChannelClosedException is thrown on a
> closed channel could be updated to check that the exception is not
> AsynchronousCloseException.
>
> As regards the change, then for consistency I would like to see
> blockingRead, blockingWriteFully and sendOutOfBandData also call
> ensureOpenAndConnected before checking the blocking mode. That will
> keep them consistent with read/write. Also the beginWrite(true) in
> blockingWriteFully should be inside the try block rather than outside
> (okay if that is done as a separate issue if needed but it's all in
> the same area so I mention it here).
>
> -Alan.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200731/8d8d930f/attachment.htm>
More information about the nio-dev
mailing list