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