7176630: (sc) SocketChannel.write does not write more than 128k when channel configured blocking [win]
Alan.Bateman at oracle.com
Thu Jun 14 01:45:16 PDT 2012
On 14/06/2012 00:28, Esmond Pitt wrote:
> I suggest the loop should only happen in blocking mode, if at all.
> Non-blocking mode programs must already cope with short writes, and
> shouldn't be held up dispatching writes, on fairness grounds. I'm not
> convinced about the need for the loop in blocking mode either, as
> applications must be written correctly, and forums are already full of war
> stories about checking write (and read) return values in java.nio and indeed
> java.net and java.io.
This patch does not change anything when doing writes with <=
MAX_BUFFER_SIZE so there isn't any loop in either blocking or
non-blocking mode (a short write in non-blocking mode is as before, it
just cause the function to return with the number of bytes written). For
> MAX_BUFFER_SIZE case this write(ByteBuffer) currently only writes up
to MAX_BUFFER_SIZE. The changes means that the blocking write will
attempt to write all remaining bytes, in the non-blocking case it will
do the same except that a short write will cause the loop to terminate
early. At some point I'd like to split the blocking and non-blocking
code paths in NIO but not in this patch.
As regards people not checking the return value, yes, we see this all
the time too. The specification sets the expectation that all remaining
bytes will be written in blocking mode so this is why it is viewed as a
regression in jdk7. As part of a follow-on patch we will need to adjust
the specification slightly as there will be cases in non-blocking mode
where all remaining bytes cannot be written, write(ByteBuffer) with an
array larger than IOV_MAX is one example that comes to mind.
More information about the nio-dev