Behaviour of SocketChannelImpl.close() in Java11 (ea+12)

[Norman Maurer]

> On 18. May 2018, at 09:10, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 13/05/2018 08:40, Norman Maurer wrote:
>> :
>>> There was no intention to break the SO_LINGER = 0 case when this code was refactored a few months ago. We can get that working again, at least for cases where the closed channels are promptly flushed from the Selectors that they are registered with. I have changes that I will bring here for review soon.
>> Sounds good �� I will happily review the changes and try out with Netty unit tests.
>> 
>> 
> That change made it into jdk-11-ea+14 so it would good if you could try it out [1]. So as discussed, if the SocketChannel has SO_LINGER enabled to a value of 0 and you close it while registered with one or more Selectors then the peer should see a "connection reset" once the channel has been flushed from all Selectors.
> 
> -Alan.
> 
> [1] http://jdk.java.net/11/ <http://jdk.java.net/11/>

Thanks Alan…

I just downloaded the latest release and tested it without test case in netty[1] . All works again as “expected”, great work and thanks for the quick turnaround. 

Bye
Norman

[1] https://github.com/netty/netty/pull/7951
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180518/2b2c71ef/attachment-0001.html>