The RabbitMQ has new exchange type which allows for delayed message delivery. You can read more about the Delayed Message plugin here and here.
The exchange works by checking message headers to determine whether the message has to be delayed, and then store message in Mnesia (RabbitMQ’s database) if necessary. All this will have an impact on performance of the exchange. To see how big the impact is, I decided to run some tests.
Recently, new plugin for RabbitMQ was created which provides support for delayed messaging. The plugin adds new exchange type to RabbitMQ which will store messages internally, using Mnesia, until they are scheduled for delivery. This provides a protection in case the server goes down. The beauty of this solution is that it keeps everything inside RabbitMQ and doesn’t require installing any additional software. It will also simplify RabbitMQ configuration when compared to solutions based on Dead Letter Exchanges and message TTL.
The plugin is currently in experimental phase, but hopefully community will provide precious feedback and allow it to become production ready.
After installing RabbitMQ on Windows Server 2012, when you add rabbitmq.config file1 and restart the service you may find that the server cannot load config file. You can verify that the problem occurred by checking log file2 (line 4):
In this article I am going to present few rules I use when selecting prefetch count value for RabbitMQ. Those rules are based on the experience I gained when working with RabbitMQ. You should treat them as a guidance and starting point, remembering that each application, network and queue topology is different. Let’s start with quick explanation what prefetch count is.
RabbitMQ allows consumers to specify the size of the limit of unacknowledged messages on a queue basis. This value is used to specify how many messages is send to the consumer and cached by RabbitMQ client library. Once the buffer is full the RabbitMQ will wait with delivering new messages to that consumer until it sends ACKs / NACKs. The main purpose for pre fetching messages is to optimise message delivering. The ideal situation is where there is a message delivered and waiting for the processor to be consumed.
Of course, caching messages on the consumer side has repercussions. All pre-fetched messages are removed from the queue and become invisible to other processors. Hence setting prefetch count to a high value will skew message distribution between different consumers.
Few people have asked me already how to start using [RabbitMQ] in .NET, so I decided to write a short post about it.
First, visit erlang’s page, download erlang distribution according to your system (either 32 or 64 bit) and install it. If you have 64 bit machine (and you really should have) than get the 64 bit distribution, otherwise erlang process won’t be able to address more than 2GB of memory.
Next download RabbitMQ server and install it. I strongly recommend to install Management Plugin, which comes with [RabbitMQ] installation. All you need to do is run following command from command prompt (you may have to navigate to RabbitMQ’s sbin folder):
This post is a follow up to the UK Azure User Group presentation I gave yesterday about running RabbitMQ in Azure.
When deciding on messaging system to use in your cloud solution, one of the consideration will be the cost. Azure offers Service Bus Queues and Topics as PaaS, but it also offers Virtual Machines (as IaaS) which you can use to host other messaging brokers, meaning you can host your own RabbitMQ cluster in Azure.
The cost of running a RabbitMQ cluster in Azure can be calculated as a monthly cost of Virtual Machines which consist the cluster. If you want to build a cluster with 3 large instance (4 vCPU, 7GB RAM) running Linux OS, then your monthly cost will be £340.91 or $535.68 (check Azure Calculator for other currencies).
With 3 node cluster you can replicate the same capabilities for you messaging broker as in Service bus: messages being replicate to 3 nodes and high cluster availability. It also gives you very decent performance of few thousand “reliable” messages per second, or tens of thousand “transient” messages a second.
Bear in mind that I haven’t included any cost related to maintaining Virtual Machines. In your calculations you will need to include that as well, but the cost depends much on the efficiency of a person maintaining Linux and RabbitMQ.