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…

Request/Acknowledge is a service design pattern wherein clients receive an acknowledgement as an immediate response while the original request is processed in the background. The acknowledgement typically contains a token for identifying the background task which can in turn be used to query the processing status of the task. This pattern is employed to reduce temporal coupling which is especially critical for requests requiring a long processing times. Instead of having the client wait for the final response a pull method for querying the status of the task or a push method for notifying the client is implemented. Similarly, the event-based asynchronous pattern in OOP shares the goal of reducing wasted wait time. Request/Acknowledge/Poll is a variation of this pattern wherein a method is provided for the client to query for the status of the task being processed. The other variation is Request/Acknowledge/Callback wherein a client is notified of task status immediately via callback mechanism. The callback variation ensures that the client receives task status information as it is generated but can be a burden to implement because the client must support the callback mechanism. Furthermore, it places the additional burden of tracking and invoking callbacks upon the server. The poll variation is simpler to implement and keeps the client in control of retrieving status information as it is needed.