For the last part of this short series, let\u2019s take a glance at some conceptual differences between RabbitMQ and MSMQ from developer\u2019s point of view. We can\u2019t cover much in a\u00a0single blog post, so let\u2019s just mention few things to get you started.<\/p>\n
Queues and exchanges in RabbitMQ are often temporary and not as long living as in MSMQ. What do I mean by that? In MSMQ, queue’s setup is usually multi-step process – you’re not only creating a\u00a0queue, but also configuring its properties and access rights. Because of that\u00a0it’s typical to do it from\u00a0management console and not from code. Once set up, queue often remains in MSMQ “forever”, i.e. until we manually delete it.<\/p>\n
With RabbitMQ, creating new queues can be simpler. I’ll just talk about queues here, but same things apply for exchanges as well. You just declare<\/strong> a queue, and it’s auto-created if doesn’t already exists. You don’t have to manually check whether a queue exists before the declaration. This alone doesn’t represent a significant saving over MSMQ way. Here’s where real difference lies – if you’re using policies to configure queue parameters, queue will automatically pick up these settings as it’s created. Also, user permissions are managed centrally too, with pattern-based matching. So, depending on how policies and user settings are set up, your newly created queue could be immediately\u00a0configured as it should be as soon as it’s created. Except for bindings, unless we use default AMQP exchange.<\/p>\n RabbitMQ itself has support for temporary queues. We can declare a queue not to\u00a0be\u00a0durable<\/strong>, in which case it will exist only until the broker\u00a0is restarted. Even more, we can set it to\u00a0auto delete<\/strong> mode, where it gets automatically deleted as soon as it doesn’t have any more consumers. Or even use\u00a0exclusive<\/strong> mode, where it can be used only from the\u00a0same connection where it was created.<\/p>\n RabbitMQ .Net client (and probably others as well) supports automatic recovery. In that mode, if there’s a network problem and connection is dropped, client will reconnect, but also declare again all queues, exchanges, binding, etc. which were declared previously.<\/p>\n With MSMQ, you always communicated through local MSMQ service, even if destination was on another machine. MSMQ stored pending messages in outgoing queues and took care of failures and retries. With RabbitMQ it’s possible to communicate with broker\u00a0over the network, so there’s a\u00a0higher probability that something will go wrong and we have to take care of potential issues ourselves.<\/p>\n RabbitMQ has ack\/nack mechanism which is used to communicate that message is dealt with correctly (ack – acknowledgment), or that there was some problem during operation (nack – negative acknowledgment). This is available both for sending and receiving messages. Also, some client libraries have built-in retry or reconnect mechanism. If not, we have to do it manually.<\/p>\n If you read Part 2<\/a>\u00a0of this series where we discussed Exchanges, you know that we can’t send to a queue directly, we always send to exchange and then it passes messages around according to its parameters and bindings. There is a shortcut to this rule, by using AMQP default exchange which allows us to put destination name in routing key. Messages will go directly to that queue without us having to configure any bindings.<\/p>\n What happens if we send a\u00a0message to an exchange and it turns out it’s unroutable? Either exchange doesn’t have any bindings, or its bindings have filters (e.g. by routing key, header property, etc) and our message doesn’t match any of them. That message will be lost. In some cases we’re ok with that. Maybe message contains some temporary information and if nobody needs that info currently, it’s not a loss if message is deleted. However, if message shouldn’t be lost, and we want to know about these cases, we can set up\u00a0mandatory<\/strong> flag and we’ll get an error if it won’t reach any destination queue. Then we can deal with that situation.<\/p>\n Since “send” operation could involve multiple destination queues, even on multiple machines, RabbitMQ can give us confirmation on whether message reached all destination queues or not. We issue\u00a0confirm.select <\/em>operation and RabbitMQ gives as ack or nack. If response is nack<\/strong>, we can either abandon publishing that message or try sending it again. Since ack requires that message reaches all destinations, it might be too slow to wait for it after each message. RabbitMQ gives us delivery tag<\/em>\u00a0<\/em>for each message we send, and since it’s autoincrementing number we can use that to ask for confirmation for multiple messages. Something like “please confirm that all messages up to this delivery tag are correctly published”.<\/p>\n RabbitMQ doesn\u2019t have Peek operation like MSMQ. When you take out a message from a queue using BasicGet operation, it will immediately be invisible to all other receivers. However, it doesn\u2019t mean it\u2019s completely removed from a queue. Message is permanently removed only after we send Ack. It’s advisable to send Ack at the end of entire processing, e.g. after database and other operations are completed. <\/span><\/p>\n If we Nack that message manually, or if Nack happens automatically because of a timeout,\u00a0message\u00a0will be requeued – it will be visible and available again in a queue. We can also tell RabbitMQ not to\u00a0requeue and just delete it instead. There’s similar operation called reject (also with requeue or no requeue) but it works for a single message only. While ack\/nack can be issued for multiple messages at once, thus increasing performance.<\/span><\/p>\n BasicGet is a manual (pull) way of consuming messages. We can also subscribe to a queue and RabbitMQ client library will trigger our code when a message arrives. This is not only API difference, but RabbitMQ treats subscriptions differently. For instance, “auto delete” queue will be deleted when there are no more consumers. However, it works only for subscribed consumers, not for BasicGet mode.<\/p>\n There’s a lot more to RabbitMQ than we could cover in this short series. Fortunately, it has excellent documentation:<\/p>\n Getting started tutorials<\/a><\/p>\n RabbitMQ documentation<\/a><\/p>\n Although RabbitMQ management console is quite good, it offers only very basic view of messages, without any additional operations. That’s where\u00a0QueueExplorer<\/a>\u00a0helps (yep, our own product) \u2013 the best way to work with RabbitMQ during development, testing, or production usage.<\/p>\nMessage acknowledgments<\/h2>\n
Sending messages<\/h2>\n
Mandatory messages<\/h3>\n
Publisher confirms<\/h3>\n
Consuming messages from a queue<\/h2>\n
Receiving by subscription (Push)<\/h3>\n
Where to go next<\/h2>\n