Bug in HeapChannelBuffer.slice()

[Phuong LeCong]

First of all I'd like to say thanks for creating such a great NIO framework. 
I've been using it extensively for most of our networking needs and it's
great.

I've run into what seems like a bug going through debug on Netty 3.2.0 CR1. 
It started when I needed to Base64 encode some outbound data, however it
seemed like one of my requests were not being sent.  Debugging through the
code and enabling the LoggerHandler, it would seem that after the
Base64Encoder the output is a BigEndianChannelBuffer that has
readableBytes() == 0.

It would seem that when there's a call to BigEndianChannelBuffer.slice() in
Base64.encode(), the slice() source has the following:

            if (length == array.length) {
                return duplicate();
            } else {
                return new TruncatedChannelBuffer(this, length);
            }

The requests that do make it, follow the "else" path and a
TruncatedChannelBuffer is returned with the writerIndex advanced to the
length.  However, if the duplicate() path is followed, the writerIndex is
not advanced and the readableBytes() returns 0 (since Base64 doesn't
actually write, but just sets bytes.

Is this the correct behavior?

Phuong
-- 
View this message in context: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Bug-in-HeapChannelBuffer-slice-tp5193644p5193644.html
Sent from the Netty User Group mailing list archive at Nabble.com.