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

Fri Sep 2 08:32:50 BST 2011

Emile

Thanks for your help...

With the headers exchanges - I had seen both sources of information you mentioned, but still didn't find it hugely useful - for example, if I want to specify a particular header can match any value when the x-match is set to 'all' - that's the sort of information I'd like to see. Maybe I am missing something? The intermediate exchange point looks good, I will look into that.

With the transactions - are they really best avoided? Or are they OK to be used as long as we understand the consequences? For example, in our environment we are happy that we will be using RabbitMQ rather than any other type of AMQP broker - and so we would be happy with Rabbit's version of transactions and their behaviour. Is there any other reason to be wary of using transactions?

Thanks again

Matt

Matthew Whitfield
Software Architect

i2O Water Ltd
4 Benham Road
Southampton Science Park
Southampton SO16 7QJ, UK

t:  +44 2380 111577
m: +44 7766 951222
http://www.i2owater.com/
Registered in the UK
5617487

-----Original Message-----

From: Emile Joubert [mailto:emile at rabbitmq.com]
Sent: 01 September 2011 18:06
To: Matthew Whitfield
Cc: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] A few questions about RabbitMQ and the .NET Client

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