Cancelled key may fail select()

[Alan Bateman]

On 11/02/2020 22:30, Simone Bordet wrote:
> Hi,
>
> On Tue, Feb 11, 2020 at 11:11 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> Do you have a reproducer?
> No. It seems to happen more frequently on the FreeBSD port of OpenJDK.
The FreeBSD man page for close lists ECONNRESET as a possible error on 
that platform. I don't see it in the man pages on other platforms. The 
OpenJDK BSD Port Project seems to be inactive so I can't quite tell 
where the port(s) are maintained now, do you know if this is just the 
macOS bits or are there are other patches applied?


> :
> I see that SelChImpl.kill() still declares throws IOException.
>
> When you say "does not throw" you mean that the native implementation
> for all OSes does not throw even if the signature declares it?
> Would be it possible for other implementations (e.g. FreeBSD) to throw
> and still comply with the signature, but be handled badly by common
> OpenJDK classes?
>
The kill implementations of the channels in sun.nio.ch do not throw 
IOException (as of JDK 13). The method still declares that it throws 
IOException because the SCTP channel implementations (jdk.sctp module) 
dates from JDK 7 and haven't been modernized/aligned with the new 
implementations in sun.nio.ch.

In any case, I think the issue you are seeing reported on FreeBSD is 
because SocketChannelImpl::kill shouldn't be propagating from the 
exception/error from close. It was fixed in JDK 13 by way of other 
changes. The reason you don't see this in JDK 8u is because it has the 
old (and problematic) async close mechanism would dup2 the socket while 
registered with kqueue. Selection operations would do the final 
cleanup/close (so couldn't fail with ECONNRESET). As I mentioned, there 
has been a lot of changes to his area in recent releases and fixing the 
issue for BSD would require back-porting a subset of the changes from 
JDK-8223353.

-Alan.