NServiceBus problems with RavenDb

I work on a .NET application that uses NServiceBus. Under the hood, NServiceBus uses RavenDb for persisting data and state. I hadn’t needed to work on this part of the application for a while, but today I needed to get NServiceBus up and running again.

Unfortunately it wouldn’t work. NServiceBus kept crashing out with the error:

Exception when starting endpoint, error has been logged. Reason: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

What had happened since I had last run NServiceBus last. Ah yes, Windows 10…

I decided to reinstall the RavenDb Windows service. You can do this relatively easily by opening a command prompt in the RavenDb folder where the raven.server.exe file lives and typing these two lines:

There was also another error being raised internally:

NServiceBus performance counter for Critical Time not set up correctly. Please run the NServiceBus infrastructure installers to rectify this problem

Because we are using NServiceBus v3 rather than v4 (upgrading our application would more than likely be painful and currently it just works – never touch a running system and all that), I checked the RavenDb version support. A colleague was running build 2910, so I decided to do the same.

After installing RavenDb again the initial problem was still apparent and a bit of Googling led me to a StackOverflow post about corrupted NServiceBus performance counters.

After rebuilding the performance counters using lodctr /R, everything started working again. Note that if you are on 64 bit Windows, you’ll need to run that command under syswow64 and not system32.

Happy NServiceBus-ing…

After putting some considerable thought and research into the various “NoSQL” or “document databases” we settled on RavenDB due to the overall features it supported, and the native implementation of Lucene. That being said, our next step will be to start leveraging the geospatial capabilities of RavenDB to augment our current full-scale GIS system and code base.

Like most NoSQL solutions, RavenDB best practices favor denormalization over composition / joins for complex documents.

That decision make reading the data very fast and easy, but it present a challenge when we need to update the Artist name. In general, it isn’t recommended to denormalize data that frequently changes, but even rarely changing properties will change occasionally. In order to solve this exact problem RavenDB offers Set Based Operations.

One thing that confuses a lot of people when they dive into RavenDB, is how to handle relations and references between documents. RavenDB is a document database and thus is certainly not built around the idea of relations. Instead, most of the advantages of document databases come from the document oriented modeling, which treats every single document as isolated and meaningful on its own, therefore reducing the number of request to the database (in order to serve a web request for instance) and enabling easy horizontal scaling (sharding across multiple servers).