Aside

Visual Studio Debugger Tips and Tricks: Run to Cursor

Run to Cursor

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.

Find other Visual Studio Debugger Tips’n’Tricks: https://mariuszwojcik.wordpress.com/category/visual-studio/debugging/

Advertisements
Aside

Visual Studio Debugger Tips and Tricks: step into specific

Step into specific

We all try to keep our code concise, so from time to time there is one line which calls several methods, like this one:

PrintMessage(FormatResult(text, ReverseString(text)));

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.

Find other Visual Studio Debugger Tips’n’Tricks: https://mariuszwojcik.wordpress.com/category/visual-studio/debugging/

Aside

Visual Studio Debugger Tips and Tricks: step out

Visual Studio excerpt

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 step out icon on the toolbar, or use Shift + F11 shortcut and the debugger will take you out.

Find other Visual Studio Debugger Tips’n’Tricks: https://mariuszwojcik.wordpress.com/category/visual-studio/debugging/

Single Responsibility Principle applied to exception logging

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.

Lets first look at an example:

try
{
    UpdateAccount(userAccount);
}
catch (SqlException e)
{
    var sb = new StringBuilder();
    sb.AppendLine(e.ToString());
    sb.AppendFormat("Sql number: {0}", e.Number);
    sb.AppendFormat("Sql procedure: {0}", e.Procedure);
    sb.AppendFormat("Sql server: {0}", e.Server);

    logger.Error(sb.ToString());
}

As you can see, the main code invokes method UpdateAccount, which we can assume will perform update in the database. In the catch block error message is constructed with exception details and logged.

The first thing which you can easily notice is that exception handling block is much bigger than the main code. When analysing this code the user will have to filter out big chunk of exception formatting.

Next, because message formatting is embedded in the method, it will have to be duplicated across code base wherever SqlException is handled. The more places it is duplicated the harder it is to update.

And finally – it breaks Single Responsibility Principle. As defined by Uncle Bob:

A class should have one, and only one, reason to change.

In the above example, the class will have at least three reasons to change:

  1. the change in handling account update (this is the primary reason for this class)
  2. change in error message formatting, including adding/removing details
  3. change in error types handled, such as adding new error type to be logged

This is problematic because adding new exception property to be logged requires re-running all tests related to this call, including regression test. Suddenly a simple change is no longer simple.

The error message formatting logic belongs to the logging framework. Use type renderer for formatting message according to your needs. To handle logging new exception types you only need to create new type renderer and register it with logging framework. You can even reuse type renderers between different applications.
And the catch block will shrinks to one line of code:

logger.Error("Updating user account failed.", e);

How to choose prefetch count value for RabbitMQ

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.

Prefetchcount

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.

Consumer types

Below are rules for selecting prefetch count depending on the consumer type.

Fast, single consumer

If there is only one consumer processing messages quickly you definitely want all messages to be pre-fetched. The optimum value will probably be something higher than 20, but setting it to anything above 50 will rarely delivery more value. Remember that pre-fetched messages are cached on the client side consuming its resources. High value will also restrict your ability to peek messages.

Multiple fast consumers

When you have multiple consumers which are processing messages fast you need to find value which keeps messages waiting for consumers as well as allows for balanced message delivery between consumers. Low value will penalise consumers as they need to wait for messages. High value will damage load balancing. I usually use anything between 20 and 30.

Slow consumers

For slow consumers message delivery time is negligible. My advice is to set prefetch count to 1 and let RabbitMQ load balance message between consumers.

Application crash and buffered messages

Let’s see what happens to buffered messages when the application crashes. Because RabbitMQ automatically puts all not ACKed messages back to the queue, if the application crashes then all cached messages will simply go back to the top of the queue.

Setting prefetch count

To set ‘prefetch’ count in RabbitMQ you have to execute basic.qos command1.

Setting prefetch count in EasyNetQ

You can set prefetch count value in EasyNetQ by including it in the bus’ connection string. Default value used by EasyNetQ is 50.
Below example sets prefetch count to 30:

var bus = RabbitHutch.CreateBus("host=localhost;prefetchcount=30");

Resources

You may find more information about prefetch count in following articles:

Some queuing theory: throughput, latency and bandwidth
RabbitMQ Performance Measurements, part 2


  1. For example of usage check Work Queues tutorial. 

How to process messages in parallel using EasyNetQ

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:
Continue reading

Tell EasyNetQ bus what Queue name to use for your messages

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?
Continue reading