Improving perf of FileChannel.transferTo() on Windows

[Alan Bateman]

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>