qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Use of AMQShortString in client side code
Date Thu, 20 Sep 2007 09:05:44 GMT
Rafael,

Is there much difference between your decoder that works on multiple byte
buffers, and a decoder that works on a byte buffer but that could be passed
a special aggregating byte buffer that pulls together several byte buffers
and presents them as if they are one buffer? That is, do you think the
latter option could be just as efficient as the former one?

The aggregating byte buffer concept sounds like a very useful re-usable
building block, and conceptually neater than a special decoder that works on
many buffers; it can simply be substituted in wherever a ByteBuffer can be
used. I'd like to pull it out of the code, and write a few tests to exercise
it, as an experiment.

Writing out the message, from an aggregated list of byte buffers, sounds
like it can be done efficiently as a gathering write.

Rupert

On 19/09/2007, Rafael Schloming <rafaels@redhat.com> wrote:
>
> Yes, except 0-10 adds another level of this since frames are the unit
> you read off of the wire, and those can't be directly parsed without
> aggregating them. So for the 0-10 transport code you either end up doing
> two full copies if you want to provide contiguous byte buffers to the
> codec, or you make the codec deal with non contiguous byte buffers. I
> chose the latter, and also stopped using the CumulativeProtocolDecoder
> as there was no need anymore.
>
> > I have discussed in the past using a special implementation of
> > ByteBuffer that can aggregate sub byte buffers to avoid copying (that
> > is currently done in the CumulativeProtocolDecoder or something like
> > that).
>
> I have something similar to this. It's not an implementation of
> ByteBuffer, it's just a Decoder object that knows how to read primitive
> AMQP types out of a list of multiple ByteBuffers. It's a bit simpler
> than a full ByteBuffer impl, but it has much the same effect.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message