Rebus and message expiration

If you have worked with NServiceBus, and you’ve tried Rebus as well, you might be wondering where that nifty [TimeToBeReceived] attribute went? You know, that attribute that you would decorate your messages with when you wanted to have MSMQ expire the messages for you to prevent your queues from clogging up with irrelevant messages if the recipient was down.

The answer is: There’s no such attribute in Rebus! And that’s because that would require your messages assembly to reference Rebus, and that should not be a requirement. Rebus allows your messages to be POCOs, so your messages assembly should be allowed to stay “plain” in that POCO sense.

How to set time to be received then?

With Rebus you set the time to be received property of your messages by attaching a special Rebus header to your messages: Headers.TimeToBeReceived. The value must be a HH:mm:ss string, e.g. "00:01:30" to set a 1 minute and 30 seconds expiration timeout on a message.

E.g. like so:

This header will be detected later on by the transport implementation (e.g. MsmqMessageQueue), which will use the approproate settings when sending the message.

In MSMQ’s case, the message will then be deleted by the queueing system when the timeout expires, which is a nifty feature that can be used to avoid flooding the queueing system with expired and irrelevant messages.

But doesn’t that require a lot of tedious manual work?

Yes – which is why I suggest you use some of the nifty hooks in Rebus to reduce the amount of tedium involved. More on that in the next post.

Contract testing with NUnit

When you’re testing your code, you’re most likely doing different types of tests – e.g. you might be doing real unit testing, integration testing, etc. In Rebus, we had the need to do contract tests[1. I’m not aware if there’s a more established word for this kind of black box test.], which is a test that ideally runs on multiple implementations of some interface, verifying that each implementation – given various preconditions in the form of differing setups etc – is cabable of satisfying a contract in the form of an interface.

In other words, for each implementation of a given interface, answer this question: Can the implementation behave in the same way in regards to the behavior we care about.

I’m aware of Grensesnitt, which Greg Young authored some time ago – and that is exactly what I’m after, only without the depending on an additional library, without the automatic stuff, etc. I just wanted to do it manually.

So, at first I wrote a lot of tedious code that would execute multiple tests for each test case, which was really clunky and tedious and would yield bad error messages when tests would fail, etc. Luckily, Asger Hallas brought my attention to the fact that a much more appropriate mechanism was already present in NUnit that would enable the thing that I wanted.

It turned out that NUnit’s [TestFixture] attribute accepts a Type as an argument, i.e. you can do this: [TestFixture(typeof(SomeType))], which will cause the test fixture type, which should be generic, to be closed with the given type. E.g. like so:

Now, if we add a generic constraint to the fixture’s type parameter, we can require that the type is a factory and can be newed up:

See where this is going? Now one single test fixture can be closed with multiple factory types, where each factory type is capable of creating an instance of one particular implementation of something, that should be tested. E.g. in Rebus, we can test that multiple implementations of the ISendMessages and IReceiveMessages work as expected by creating a factory interface like this:

where an implementation might look like this:

and one particular test fixture might look like this:

The advantage is that it’s much easier to see if new implementations of Rebus’ abstractions can satisfy the required contracts – and with the way it’s implemented now, various implementations can have different setup and teardown code, and their fixtures can belong to a suitable NUnit category, allowing Rebus’ build servers to run only tests where the required infrastructure is in place.

Official Rebus documentation

Rebus logoHello world!

Due to the fact that there’s actually a few people using Rebus in real systems now, and also to give myself some insight into whether I have thought things through ;), I have started working on the official Rebus documentation.

For now, it resides on Rebus’ GitHub wiki – if you’re interested, you should check it out.

Also, if you think that something is missing, please don’t hesitate to let me know!

Locking oneself out of SQL Server and the good old registry diff trick

Probably one of the oldest tricks in the book, but definitely one that should not be forgotten, is the Good Old Registry Diff Trick. You see, the other day I accidentally locked myself out of my local SQL Server by making a classic mistake: I deleted my own login!

Well, actually I had created a SQL login that I planned on using after having deleted the login used by my Windows account, but I had forgotten til enable the “Mixed mode authentication” setting, and thus only Windows authentication was allowed.

A little bit of Googling revealed a blog post that mentioned a “LoginMode” key somewhere in the machine’s registry, but my registry did not contain the branch mentioned in the blog post.

Good Old Registry Diff Trick to the rescue!

I went into another machine with a functional SQL Server that I could access, and made sure that only Windows authentication was allowed. Then I used Regedit to export the entire contents of the HKEY_LOCAL_MACHINE hive into a file called “before.reg”. Then I went in and changed authentication mode to “Mixed mode”, and repeated the export into another file, “after.reg”.

Then I loaded a diff tool with the following two files, giving me this:

which revealed that the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQLServer] branch had the “LoginMode” key, which I could then change from “1” to “2” in order to allow “Mixed mode authentication” on my almost-impenetrable SQL Server, allowing me to log in.

Thank you, Good Old Registry Diff Trick.

Just a thought on the MVP program

Today, I read Davy Brions latest post, “Most Valuable Professionals? Give me a break.” I have to admit that I was a little bit saddened by Davy’s experiences with the MVP program and its representatives in Belgium, because my view of the MVP program has almost always been positive.

I know that the program is notorious for its obscure election process, and I followed Rob Eisenberg’s hazzle back in January, yet I am confident that the MVP program is a good thing – because all the MVPs here in Denmark that I know of are genuinely cool people, who are working hard on interesting projects, and who still manage to find time and energy to spread good vibes about technology that widens everybody’s horizon. I simply do not know any MVPs that are not awesome technologists!

Another thing is that I was recently given the MVP award – and I can honestly say that I do NOT scratch Microsoft’s back unmerited in any way!

I am pretty invested in the open source .NET world, and when I give talks, I talk about stuff like Castle Windsor, MongoDB, and NServiceBus. And personally, I am much more an indie-underground-micro-framework-kind-of-guy, than I am an enterprisey blessed-by-Microsoft-kind-of-guy, even though I tend to work in enterprisey environments. I just happen to enjoy working with C# and the .NET stack, both professionally and in my spare time, and I guess that’s what shows when I communicate with people about software development.

What I am saying is this: The fact that I get an MVP award can only be a sign that Microsoft (at least in some regions) actually want to encourage developers to be active and contribute to the .NET communities in various ways, even though they’re not necessarily praising Microsoft at every occasion. I guess Microsoft (still: at least in some regions) realize that active software developers are good for the .NET ecosystem as a whole, and in my eyes that’s what the MVP program is about.

I guess I just wanted to chime in with a positive MVP story πŸ™‚

Check out The Snoop

It’s very very alpha, even more alpha than Rebus itself – but here it is: Rebus Snoop – a tool to aid developers and operations in managing their Rebus queues.

The goal of The Snoop is to provide that little extra bit of tooling that will give you a feeling of transparency and confidence when developing and operating systems based on Rebus.

At the moment, it’s extremely basic – it allows you to see which queues exist on a given machine, and it will display the contents of the selected queue.

When a message is selected, various pieces of information from the message will be shown in the panel to the right.

If the extension element from the MSMQ message can be properly deserialized into a dictionary of headers, and those headers are proper Rebus headers, they will be displayed at the top.

If the rebus-encoding header is present, The Snoop will attempt to decode the message body and show the contents in the windows to the right.

If the rebus-source-queue header is present, The Snoop will unlock the “Return to source queue” button, allowing you to retry the selected messages.

You can go to Rebus’ wiki page on the Snoop if you want to read more about The Snoop.

I’d be grateful if you would report any problems you may encounter and/or crazy feature requests to Rebus’ issue tracker.

How to get up and running with Rebus

Now that Rebus is present on NuGet, it has become extremely easy to get started. This small guide will show how to build a simple TopShelf service, that will send a message to itself. It should be pretty easy to extend this to a more complete example with multiple services, but let’s just keep it really simple for now.

Create the host process

First, we create a TopShelf host process that has all the necessary stuff to be able to run and be debugged, as well as installed, uninstalled, and be managed as a Windows Service. Precious stuff when you’re building backend processes.

Create a Console Application

Do what the header says – and change the target framework from that bastard “.NET 4 Framework Client Profile” to “.NET 4 Framework”.

Go get TopShelf

Open a package manager console (we’ll need it for the Rebus alpha packages), and

For some reason, you need to download Log4Net manually, even though TopShelf depends on it.

Configure Log4Net and declare the TopShelf service

Now, do something like this in your Program.cs:

and then add some XML to your app.config:

Now you should be able to run the service and see a buttload of log statements, courtesy of TopShelf.

Insert Rebus

Now that we have the host process up and running, let’s make the program do stuff.

Let’s get Rebus

Go to the package manager console again, and do this:

Let’s configure and use it!

Now, you should be able to implement your Start and Stop methods like this:

Now, in order to make the container.Register(...) line from above compile, you need to let Program implement IHandleMessages<string>. Try adding something like this:

If you run the program now, you’ll get some kind of error, saying that the input queue name is invalid. That’s because we haven’t configured Rebus yet. Let’s do that by modifying app.config by adding this:

The InputQueue attribute above tells Rebus to receive messages from the RebusTest.input queue, and the <add ...> elements says to send messages of the System.String type to the same RebusTest.input queue.

Let’s run it

Now you should be able to run it and see something like this on your screen:

If you get the same w00t!!!: HELLLLLO WORLD!!!1 in your console, it means you’re ready to start building stuff with Rebus πŸ™‚

Announcing: Rebus

Preface

Friends and acquaintances might know that I’ve spent the last 6 months or so of my pastime, hacking on something I call Rebus. To cut a long story short, I can tell you that I am a happy NServiceBus user who became very sad when NServiceBus went from being free to requiring a commercial license – not because I think NServiceBus isn’t worth spending money on, but because I think it hurts the adoption of NServiceBus.

Speaking for myself, I have already refrained from using NServiceBus in a couple of smaller projects, where it would otherwise have been an awesome addition.

I seriously considered forking the 2.0 version of NServiceBus, which is licensed under Apache v. 2.0, but I was overwhelmed by the sheer size of the project. This led me to re-implement my favorite features of NServiceBus as Rebus, trying to focus and stay lean along the way.

And here it is: Rebus

Rebus – the core – depends on .NET 4 only. And since .NET 4 has MSMQ, ADO.NET, and binary serialization, you get to send and receive messages transactionally and persist your stuff in SQL Server without anything but Rebus core.

3rd party integration (like e.g. MongoDB, NewtonSoft JSON serializer, etc) is provided through small, dedicated add-on projects. This granularity makes it easier to manage your own dependencies.

Update: And since JSON serialization was deemed to be the preferred form of message serialization, it has been ILMerged into Rebus core since right after this announcement. Therefore, JSON serialization is included in the box and is the default.

There’s currently two ways to get started with Rebus:

  1. Instantiate RebusBus manually, filling in the ginormous constructor with implementations for how you want the bus to run.
  2. Use the configuration API.

Let’s try the configuration API – with the following snippet of XML in your app.config:

and the following piece of code in your app:

you should be up and running with a Rebus bus.

That was a small teaser – there’s more blog posts on the way, I promise πŸ˜‰

So, what’s the state of this?

Well, that’s actually the whole point of this blog post – I’m currently in a situation where I really feel like putting Rebus to some serious use, but I cannot justify foisting it on a client until I have a big project to prove its worth. And I cannot prove its worth in a big project until I have a client I can fob it on.

That’s where you come in! πŸ™‚

You:
  • You’re building something – it’s not totally mission critical, as in human lives depend on it, but it’s still something.
  • You want some nifty service bus technology to help you build a loosely coupled architecture that will allow your project to flex and bend and integrate with stuff in many years to come.
  • You wanted to use NServiceBus because it’s cool, but you can’t afford the cost up front.
  • You’re reading this blog post, or someone you know read it and is now telling you about it…

If that’s you, then you should meet Rebus!

Rebus:
  • Absolutely free to use and abuse.
  • Very very similar to NServiceBus, allowing you to migrate to NServiceBus some time in the future if Rebus is not enough for you.
  • Pretty simple.
  • Comes with unlimited[1. Within reason, of course – I have a day job, a wife, and two kids, so I’m not answering emails 24/7 – but I’ll go to great lengths to help you get a smooth adoption of Rebus – because that’s just how much I care :)] support from its author.
  • Did I mention it was free?
A match made in heaven?

If you have the slightest bit of interest in what I’m suggesting, please contact me – either via email or on Twitter – and then we’ll talk about what Rebus can do for you. Oh, and please don’t hesitate to contact me – even if you’re NOT planning on using Rebus, I’d like to know why you picked NServiceBus, MassTransit, or Rhino Service Bus instead.

If you’re just eager to try it out, feel free to Install-Package -Pre one or more of Rebus’ NuGet packages.