hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Truncated content-length delimited message bodies with sendfile
Date Wed, 20 Feb 2013 20:35:00 GMT
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message