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):
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:
$exception as FaultException<ApiFaultDetail>
and you can access all the information. In my case the problem was invalid CampaignId.
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.