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 Wed, 19 Sep 2007 10:49:27 GMT
Also, consider the example of the low-level back to back client, that moves
messages between brokers. It wants to do as little decoding as possible.
Good reason to have lazy decoding at least at the low-level API.


On 19/09/2007, Robert Greig <robert.j.greig@gmail.com> wrote:
> > >> I believe what would be optimal is to use the CharSequence interface
> > >> everywhere. This way String values passed to us by an application
> could
> > >> be directly passed all the way down the stack and encoded directly
> onto
> > >> the wire without an additional copy, and incoming data could be
> > >> efficiently decoded into a private impl of CharSequence that could be
> > >> converted to a String on demand.
> It already implements CharSequence but in the client implementation I
> don't see why using that interface is particularly useful.
> Anyway there are sound performance reasons even in the client for
> using AMQShortString to wrap an underlying buffer slice since it means
> we don't have to decode things up front.
> Consider a client reading a message a message which has say 10 string
> message properties (JMS properties). These are encoded in a field
> table in AMQP. The client app may or may not use these properties - in
> my experience you generally don't need all of them particularly if the
> message is generic. By using the short string you can lazily decode
> only when the client app asks for a property value.
> RG

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