On Wed, 2013-02-27 at 11:03 +0530, Asankha C. Perera wrote: > Hi Oleg > > 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. > Yes, I see.. it would have been great if FileChannel.transferFrom() > returned -1 as well, without hiding that underneath the JDK layer, when > actually encountered
Absolutely. I see no reason why FileChannel#transferFrom() should be behaving this way. This looks like a bug to me. > > 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. > What if we make our LengthDelimitedEncoder try to read into the session > buffer, if bytes read is found to be zero? This may not be optimal, but > at least, results in the correct operation. > > bytesRead = dst.transferFrom(this.channel, position, > count); > if (bytesRead == 0) { > bytesRead = this.buffer.fill(this.channel); > } > > regards > asankha > I would try reading into a ByteBuffer with zero remaining capacity. Hopefully this would give us channel status without moving any data into the buffer. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
