Improving perf of FileChannel.transferTo() on Windows
Alan Bateman
Alan.Bateman at oracle.com
Mon Oct 20 14:55:24 UTC 2014
On 17/10/2014 14:45, Valery Kopylov (Akvelon) wrote:
>
> Hello,
>
> To make a long story short, we face two potential issues:
>
> Issue 1: TransmitFile() truncates socket buffer.
>
> Solution: Currently transferTo() receives position at file and count
> of bytes to be transmitted. We could define a threshold: when
> transmitted data size exceeds it, we flush socket buffer and use
> TransmitFile(), otherwise transferTo() uses other ways of file
> transmitting.
>
> Issue 2: transferTo() is now working only synchronously.
>
> Solution: We could always open socket with WSA_FLAG_OVERLAPPED option
> -- it does not make all socket operations asynchronous by default,
> just allows that. Then transferTo() is called in overlapping mode or
> not, depending on socket mode that has been selected in
> configureBlocking().
>
> Alan, do these solutions appear to be acceptable?
>
>
For #1 then I think we just need a guarantee that a write, immediately
followed by a transferTo, will send the bytes over the wire in the
expected order. I think the original concern with TransmitFile was
ambiguity in the docs as to whether it could bypass bytes queued in the
socket buffer.
For #2 then transferTo is synchronous (there is no asynchronous version
at this time). If the target channel is configured blocking then
TransmitFile may be an option. However if the target channel is
configured non-blocking (which is still synchronous) then it's not clear
that it's a match for TransmitFile (assuming that TransmitFile is
blocking or asynchronous).
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20141020/7db008ed/attachment.html>
More information about the nio-dev
mailing list