Messages published in 7 2014

RabbitMQ doesn't recognise config file on Windows Server 2012

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):

=INFO REPORT==== 18-Jul-2014::14:29:15 === node : rabbit@SERVER home dir : C:Windows config file(s) : c:/Users/admin/AppData/Roaming/RabbitMQ/rabbitmq.config (not found) cookie hash : cYraOgE45mJWvKAUixyWHw== log : C:/Users/admin/AppData/Roaming/RabbitMQ/log/rabbit@TRP2721.log

To solve the problem you need to uninstall RabbitMQ server and install it again.

To prevent the problem in future installations you may create or copy the config file[^1] before installing RabbitMQ server.

I would like to thank Greg Woodbury who found that solution and posted it on (!topic/rabbitmq-discuss/DPJjc0dbZ5E)[rabbit-discuss google group].

  1. Config file default location on Windows is %APPDATA%RabbitMQ 

  2. Logs can be found in %APPDATA%RabbitMQlog folder. 

Visual Studio Debugger Tips and Tricks: pseudovariables

There are two pseudovariables available in debugger when running C# or VB.NET project: $exception and $user. The former one relates to the last exception while the latter one displays information about the account which runs the application. I haven’t found much use for $user pseudovariable, but the $exception proved to be very useful in cases where I need to cast exception to a specific type.

For example, when working with remote WCF services, the service can indicate error through FaultException(TDetail), where TDetail is an object containing error details. The problem is that when debugger breaks on exception and you click View Detail…, not all properties will always be accessible. I came across this problem when working with Bing Ads services, but also when handling SoapExceptions while using Google AdWords services. In case of Bing Ads, the exception thrown will be FaultException<ApiFaultDetail>, where Detail property contains information buried in either BatchErrors or OperationErrors collection. Unfortunately, neither of those will show you more than the type name (see figure-1).

To get access to those properties you have to cast the exception to FaultException<ApiFaultDetail> type. You can easily do that without stopping debugger and modifying the code. Just cast $exception pseudovariable to given type in the watch window:

csharp $exception as FaultException&lt;ApiFaultDetail&gt;

and you can access all the information. In my case the problem was invalid CampaignId.

Find other Visual Studio Debugger Tips’n’Tricks:

Cost comparison between Azure Service Bus Queues and RabbitMQ

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.

MSTest breaking changes in VS2013

Over three years ago I posted a blog showing how you can extend MS Test to verify that code under the test throws expected exception with given message. The solution extends MS Test with new test attribute and reports assertion error when either exception type or message doesn’t satisfy expected values. It is based on the way Microsoft implemented ExpectedExceptionAttribute and works well until you move to Visual Studio 2013.

Unfortunately there are breaking changes in the way VS2013 test runner is working, and as a result the extension doesn’t work any more.