qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: Use of AMQShortString in client side code
Date Thu, 20 Sep 2007 11:19:05 GMT

Robert Greig wrote:
> On 20/09/2007, Rafael Schloming <rafaels@redhat.com> wrote:
>> Robert Greig wrote:
>> That depends on the details of how tokenizing would work. It's not 100%
>> clear to me how you'd apply a generalized tokenizing scheme to AMQP as
>> some shortstrs are intended for the broker to interpret, and some
>> shortstrs are intended for the receiving client to interpret.
> I had assumed there would be a type TokenizableShortString in the
> protocol which the broker would always have to interpret and that
> would exist only in places where it made sense (i.e. where you would
> always be parsing it anyway). But thinking about that further now,
> there are clearly some problems with that such as whether you allow
> such things to be squirreled away inside field tables etc.
>> Defining a scheme that is specific to exchange name and routing key is
>> probably just simpler and easier. And of course making it fixed width
>> permits easy access to hardware for monitoring and acceleration.
> What length is being considered? I am just concerned that it may be
> quite long if it's to be useful, or there needs to be a namespace
> associated somewhere else e.g. with a producer (not a concept that
> exists currently) or consumer. For example you might want to create a
> queue called:
> com.megabank.ib.fixedincome.repo.IncomingRepos
> which has length 46.

I don't think we would replace exchange names and routing keys, just 
provide the ability to refer to them in a more efficient manner, e.g. 
perhaps use a two byte destination field that must have been previously 
assigned to a long format destination. But as I said this is 0-11 stuff, 
so the details aren't nailed down yet.

>> I could do this, but my code already uses String in the API and it
>> already lazily encodes from String->ByteBuffer, so I think this would be
>>  functionally equivalent to what I'm doing now.
> So if I understand your comment correctly that sounds like a plan?

Perhaps I didn't understand your suggestion. It sounds to me like it is 
the same thing as doing nothing at all. The generated API would use 
String and there would be no copying on encode, however that still 
leaves the overhead of copying and unicode character conversion on 
decode. It is the latter part that using AMQShortString or the 
CharSequence interface can avoid.


View raw message