[rabbitmq-discuss] A few questions about RabbitMQ and the .NET Client

[Emile Joubert]

Hi Matthew,

On 01/09/11 16:11, Matthew Whitfield wrote:
> I have a few questions – and I’d be very grateful if someone could point
> me in the right direction as to where to read more about the answers.
> 
>  1)      Headers exchanges
> 
> a.       I can see headers exchanges mentioned on
> http://www.rabbitmq.com/tutorials/amqp-concepts.html but I can’t find
> any reference to it in the .NET client (for instance, it’s missing from
> the ExchangeType class) – even though the prototypes for ExchangeDeclare
> and QueueBind would seem to allow for a headers exchange to be handled.
> Is this just something that is ‘on the list’?

You are right, ExchangeType omits the header exchange for some reason.
I'll make sure that gets added. The ExchangeType class could be
misleading though. The AMQP extension mechanism means that it is not
possible to tell ahead of time which exchange types exist on the broker.

You can supply the string "headers" to Model.ExchangeDeclare() instead
of using ExchangeType. The header exchange type is fully implemented in
the broker though.

> b.      I can’t find any documentation on exactly how header matching
> works. I can see it mentioned in section 3.1.3.4 of the AMQP 0.9.1 spec,
> but I can’t see any examples. For instance, if I wanted to match on
> messages where the ‘type’ header was ‘action’, the ‘sub-type’ header
> contained any value and the ‘source’ header was ‘distribution’ – would
> that be possible?

The specification is a good source of information. Also see
http://www.rabbitmq.com/tutorials/amqp-concepts.html#exchange-headers

There's no explicit support for booleans, but you can emulate this with
exchange bindings. If you bind an intermediate exchange and a queue in
series then both bindings have to match before messages will end up in
the queue.

> 2)      TxSelect, TxCommit and TxRollback
> 
> a.       I can’t really find any good examples of the usage or
> implications of transactions. My use case is that I want to receive a
> message, then generate 100 messages which either all get routed to their
> queue or not (basically an atomic publish) before acking the message
> that I receive. This is, in part, to allow for message durability to be
> handled in the broker (as per the ‘Not on message persistence’ that is
> about two-thirds of the way down

A better way to guarantee that messages have safely been written to disk
is to use publish confirms:
http://www.rabbitmq.com/extensions.html#confirms

> b.      While researching this, I found a recent commit which has the
> comment ‘don't use tx in examples. The less it's mentioned the better.’.
> Why is that?

Take a look at http://www.rabbitmq.com/specification.html#tx for
information on the changing support for transactions.

> c.       In that commit, a message was changed to mention BasicQos
> instead of TxCommit – is that really the intention? Is there anywhere I
> can read more about that as the API documentation doesn’t give much away…

I assume you are referring to
http://hg.rabbitmq.com/rabbitmq-dotnet-client/rev/270f6d6a4b1c

That relates to section 4.4 in the .net user guide:
http://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v2.6.0/rabbitmq-dotnet-client-2.6.0-user-guide.pdf

In that case the point being made is about race conditions, which holds
regardless of which API method is used. You should not assume that the
code is equivalent.


Regards

Emile