Emmanuel Lecharny wrote:
이희승 (Trustin Lee) wrote:
On Wed, 21 May 2008 10:08:27 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> wrote:
Another things would also be to get a byte[] getBytes( in length )
method returning as much bytes as possible, up to a length. If the
number of available bytes is below the length, the returned byte
array will only contains the available bytes, and it will be up to
the decoder to deal with it. The idea is to avoid calling the
element() method for every single byte we want.
It sounds similar to ByteBufferQueue.pollSlice(int length), but
pollSlice() returns null when there's not enough data.
Would be better to returns what has already been read. Sometime, you are
just proxying the data, and you want to send it to the next consumer as
soon as you get some. Otherwise, the queue will buffer potentially
gigantic data in memory. (This is something we experimented with
JpegPhoto data in Ldap, this is the reason I mention it).
Soooo.. Let's suppose I was writing a kind of proxy that receives
messages and relays parts of those messages to several clients.
I'd get the relayable part of the message with a slice() operation.
My decoder would then make a message object with the ByteBufferQueue and
send it for further processing.
For the clients my encoder would first write some header stuff with the
offerXX() methods.
Then I think I'd need a method that offers a ByteBufferQueue (or
Iterable<ByteBuffer>).
I think that the above use case works fine when using heap buffers, as
when there are no more references to the message object the sliced
buffers should be freed as well. But would I need to do something extra
to make it work with direct buffers?
-Eero Nevalainen
