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 01:00:26 GMT
Robert Greig wrote:
> On 19/09/2007, Rafael Schloming <rafaels@redhat.com> wrote:
> 
>> One of the previously discussed improvements for 0-11 is to define a
>> fixed width destination or address type that can be used to efficiently
>> represent the exchange name + routing-key (i.e. something akin to an IP
>> address). I suspect this would actually make the whole issue somewhat
>> moot since shortstr decoding would be eliminated entirely from the
>> critical path of the broker.
> 
> What advantages would that have over variable width plus tokenizing?

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.

For example the broker would clearly be expected to interpret tokens in 
the exchange name + routing key, but what happens if a token is used in 
the headers field table? Is the broker expected to convert it to a non 
tokenized shortstr? If so then that is a significant burden for the 
broker. If not then how does the recipient know how to interpret the token?

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.

>> To be clear I'm not against using CharSequence. Right now I'm just
>> trying to nail down whether AMQShortString is a necessary API choice or
>> simply an optimization. If it is the former there isn't much wiggle
>> room. If it is the latter I think there are a number of reasonable
>> alternatives, and using CharSequence would definitely be high on my list
>> to try.
> 
> Thinking about this further, can your generated API not present
> whatever it wants to users (e.g String just like JMS). We can optimise
> AMQShortString so that it lazily encodes String->ByteBuffer. That
> being the case, your API can create AMQShortString on behalf of the
> user to make is "easy" to use, there is no performance hit and we
> don't limit ourselves to CharSequence and avoid Rob's concern about
> using instanceof or casts.

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.

--Rafael

Mime
View raw message