RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v15]

[Alan Bateman]

On Thu, 23 Dec 2021 09:48:00 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unused imports
>   
>   Signed-off-by: Markus Karg <markus at headcrashing.eu>

> Looking at the fact that selectableChannelOutput() utilizes Channels.newInputStream() it comes to my mind that [Trisha Gee reported](https://trishagee.com/2021/12/21/simple-network-connections-with-java-a-problem/) that Channels.newInputStream() produced an endless hanging of her apparently correct code, and it was gone once she replaced it by Channels.newReader(). While she reproduced that on a Mac, it might be the same cause even on Windows. Trisha currently is working on a reproducer, but she already detected that _her_ endless hanging is definitively a thread waiting for the blocking lock. This sounds similar to what you wrote above. So maybe the problem is not inside of TransferTo, but inside of ChannelInputStream?

I think the hang in JDK-8278369 is specific to the Unix domain socket implementation of Pipe on Windows 10+ and Windows Server 2019+. More specifically, I think the issue is closing the sink after a large number of bytes has been written does not always cause a reader on the source side to wakeup with EOF. As a test, I changed the implementation to use TCP sockets unconditional (so it works like Windows 8 or Windows Server 2012 or 2016) and I cannot duplicate the issue. We need to look closer at this in the new year.

I looked briefly at the chat server and it has a number of issues.  There is a ArrayList mutated and read from several threads without synchronization. There are several issues that are possible when a chat client does not keep up, this will eventually cause the chat server to hang (a thread blocked on the PrintWriter) and all other threads will eventually blocking trying to echo the messages. So from a quick look, I don't think it is anything to do with the issues we are discussing here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6711