On Tue, 2013-02-19 at 17:27 +0530, Asankha C. Perera wrote: > Hi All > > It seems like the FileChannel.transferFrom(ReadableByteChannel src, long > position, long count) method does not throw the documented / expected > IOExceptions when a remote party closes its side of a connection. The > method instead keeps returning that 0 bytes was read, while internally > it sees a -1 on an attempted read, which it hides at the Java source > code level. > > This causes our LengthDelimitedDecoder to fail to detect such truncated > message bodies / connection close events. Interestingly, the > channel.isOpen() always returns true, even when tcpdump and netstat > shows that the remote end of the connection had closed. > > I am attaching a small test class which demonstrates this.. I do not > believe it would be possible to change the behavior of the JDK - can we > work around this? > > regards > asankha >
Hi Asankha The behavior of Channel#isOpen() is correct. A channel can be open locally (or half-closed) even if it ha been closed by the remote peer. As long as the channel is half-closed it should return -1 on all read operations instead of throwing an I/O error. The problem is this utterly crazy implementation of FileChannelImpl http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/nio/ch/FileChannelImpl.java#607 I do not see a reasonable way of working around this insanity. The only thing we can do is to plea to Oracle to fix it and pray they would heed. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
