[rabbitmq-discuss] Using .NET types as routing keys

Thu Apr 14 06:18:46 BST 2011

Nice summary.

> 2. To instance your handlers with IoC  (using Castle Project for
> example) depending on your routing keys. This is the choice I tested
> and works good.
>
Not sure what you mean here.  Like with a property of some kind?  What
configuration mechanism are you plugging in via IoC.  How is it selected?

> 4. Not using routing keys: To send your entities encapsulated in a
> fixed container with at least 2 fields (messageBody, messageType).
> Every time you receive a message you need to deserialize the envelope
> and read the "messageType" field and deserialize the messageBody (it
> should be an array of bytes) which holds your business entity. This
> approach is not faster as others due to the need of deserialize twice.
>

you could always do both, and deserialising a messageType could be very
fast.  For example, a 4 byte short integer could be: a. unencoded,  b. we
know that it starts in byte array position zero, and  c. the messageBody
starts in position 4 and stops at length-1.  Sounds fast.

Likewise a fixed length string of 10 or 20 chars is going to be fast too if
an int isn't meaningful enough.

Maybe version the message in an AQMP header... or version it yourself (byte
0).

This "packet" approach worked for TCP/IP... and I *think* TCP/IP did okay in
the end.

Once you decide, you've got to leave it baked in.  Otherwise, you've only
got (2^8) chances to change your mind assuming a 1 byte version number.

The advantage of not using an AQMP header is just that my read on the spec
was that they only guaranteed that the body field would be there in the
future.  Are these tags getting more cetain yet?

-Steven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110414/708d0ce6/attachment.htm>