When you consume messages from [EasyNetQ] bus you do not need to worry about naming and creating queues or exchanges. That’s done for you. The framework will use a pattern when generating name for the queue which is based on strongly typed name of the message type and consumer’s subscription id. Similar happens when generating exchange name. But is there anything you can do to change this behaviour?
Using Advanced bus
[EasyNetQ] gives you an Advanced bus which allows to manually create and manage queues, exchanges and bindings. You can use it to control queue names but it may be an overkill if you want only to control names.
When the bus has to resolve queue or exchange name it is using an instance of IConventions type. The standard implementation takes strongly typed name of the message type and appends subscriber’s subscriptionId to the end. By providing own implementation you can control the way exchange and queue names are generated.
The IBus interface from EasyNetQ framework has SubscribeAsync() method which allows easily to span message handling between different threads. It uses standard TPL Tasks for delegating handler execution. Depending on the application, you may create Tasks with LongRunning flag, which provides a hint to the scheduler that additional thread may be required1 and it should avoid using a ThreadPool2. Below example shows how to register parallel consumer:
var bus = RabbitHutch.CreateBus("host=localhost");
bus.SubscribeAsync("sub1", message => Task.Factory.StartNew(() =>
// long running message handler
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.
In the previous post How to log exceptions I said that you should let your logging framework handle exception logging. In this post I will explain why it is a bad idea to generate log messages in the catch block.
How many times did you step into a method just to realise you didn’t want to? Sometimes it is a simple, short method and you can step through it. Other times it is one of those monstrosities spanning for dozens of lines, or a recursive function. Instead of stopping debugger and starting again to avoid the mistake you can actually step out from the method. Just click icon on the toolbar, or use Shift + F11 shortcut and the debugger will take you out.
When debugging your code and you want to step into one of the “outer” methods, either FormatResult or PrintMessage in the above example, then right click in the code window and select Step Into Specific option. The Visual Studio will show you list of all methods you can step into. Just click the one you want to debug and debugger will break there.
Imagine, you are in the debugging mode and the next statement is a loop. You do not want to step into this loop and waste time on iterating over items but you also do not want to step out of the method. What you can do is to place cursor in the line you would like the debugger to break and select Run To Cursor option from context menu (shortcut: Ctrl + F10). It is an easy way to jump through the code, breaking in chosen places to peek on variable values.
You can even use Run To Cursor for starting an application and breaking in selected line.
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 is the second post in series about [EasyNetQ]. In the [first post] I am explaining how to install [RabbitMQ] and write simple application which publishes and consumes string messages.
Complex type message
Usually you will need to send more complex types than string. Fortunately it is no harder than sending string messages. All you need to do is to create library project which will contain your message types and share it between publishers and consumers.
Load the example application you made in the [first post] and add new Class Library project to the solution named Messages. Add new class PersonName to that project which will represent persons name:
you do it wrong! It makes extremely hard if not impossible to find out what went wrong in the application.
To be able to successfully debug application from log files you have to log at least: exception type, message, stack trace and, recursively, inner exceptions. For more specific exceptions you also want to log their properties. And then there is an AggregateException for which you need to log all aggregated exceptions.
When designing your system you have few options on how the messages will be delivered to your consumers:
messages are delivered in round-robin fashion – this is a great option for distributed, load balanced processing;
messages are delivered to all consumers – this is the option to use if there are different processors for given message;
hybrid solution where some consumers are getting messages in round robin fashion and other are getting all messages;
In the round-robin delivery, the messages are automatically distributed between all consumers. By manipulating prefetchcount setting you can easily achieve load balancing. This scenario is great when there are many consumers doing the same type of processing. The example will be an order fulfilling system with few processors receiving orders. In the heavy load times you can spin extra consumers to cope with additional work, and the system will automatically deliver next message to free consumer using round-robin fashion.
This post was written as an answer to one of the questions on EasyNetQ user group.
The main principle of EasyNetQ bus is simplicity. It greatly abstracts nuances of communicating with RabbitMQ giving developers time to concentrate on writing the core application. The framework is great and makes processing messages really simple. But there are few scenarios when this simplicity becomes a small pain. One of those times is when you want to gracefully stop the application allowing it to finish processing current message.
This post is rather lengthy but I wanted to provide good explanation.
In the last Visual Studio Debugger Tips’n’Tricks I showed Run To Cursor option which allows for running debugger and breaking in selected line. Today I am going to present another option called Set Next Statement.
Set Next Statement (shortcut: Ctrl + Shift + F10) is very useful feature and allows to move execution pointer to selected statement. This can be used to not execute statement(s), like skipping line 27 in above example. It can also be used to run statement(s) again, by simply selecting Set Next Statement on the line already executed. When combined with editing variable values, this is a very powerful tool.
If you a mouse person, you can easily Set Next Statement by moving yellow arrow () on the left.
Today’s Tips’n’Trick is one which I value a lot. Lets say you are in the debugging session and you look at the Call Stack window to check what methods were invoked so far. You can see assembly names, method names, line numbers – even parameter types and names. But you cannot see parameter values! If you want to check what was the value of the input parameter you have to double click the line and check it’s value in Autos or Locals window. To compare values between methods you will have to jump back and forth.
But wait! There is a better way to do it. Right click in the Call Stack window and select Show Parameter Values option. Once selected, the parameter values will be displayed in the Call Stack window along with parameter names and types. This feature is extremely useful when debugging recursive functions.
If the parameter is a complex type, you can control what will be displayed by annotating the type with DebuggerDisplayAttribute.