Improving perf of FileChannel.transferTo() on Windows

[Kirk Shoop (MS OPEN TECH)]

From: Alan Bateman [mailto:Alan.Bateman at oracle.com]

On 21/10/2014 11:56, Valery Kopylov (Akvelon) wrote:

Please confirm that there are no evidences of socket buffer truncation by TransmitFile, just ambiguity in the docs. I tried to reproduce it in a simple application but all bytes were sent successfully and in correct order.
If so, we do not need any additional changes above the existing patch.
I can't find too much on the original tests that were done. You may be right that it was just ambiguity in the docs but it would also be good to double check that when the peer is congested and the socket buffer fills that TransitFile will always queue behind the socket buffer.
We asked the current owners of TransmitFile about the implementation and received this response:

"So, the Winsock app issues a WriteFile() or send() or WSASend(), the call returns (which may return WSA_IO_PENDING or inline success, it doesn't matter), and then the app issues TransmitFile. . .

In this case, the data from TransmitFile is going to follow the data from the WriteFile/send/WSASend call. Additionally, if you first issue TransmitFile, and while the TransmitFile request is pending, you issue WriteFile/send/WSASend calls, then also in this case Winsock will ensure to queue the data from WriteFile/send/WSASend calls behind the data from the TransmitFile call.

In summary, the data order is preserved by Winsock as long as you issue a mix of TransmitFile/WriteFile/send/WSASend calls in serialized fashion (without necessarily waiting for any pended overlapped calls to be completed). If you issue any of these calls concurrently from multiple threads, then all bets are off in terms of data ordering."

Are you going to update the patch to only use this path when the SocketChannel is configured blocking?

Yes, we will post a new webrev when we have changed the code to only apply to blocking sockets.

Thanks,

Kirk

Developer
Microsoft Open Technologies, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20141021/2aeccffe/attachment-0001.html>