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…

Auto-generating documentation and SDKs in ASP.NET Web API

Whilst I am a big fan of ServiceStack for building REST APIs, it switched last year from a free open-source tool to a licensed business model. For small open source projects without a commercial backer, it means that we have to take a second look at ASP.NET Web API, Microsoft’s own offering.

If you are developing commercial REST APIs then please check out ServiceStack and the hard work Demis Bellot is putting in to the project. He makes awesome products and takes care of his customers.

The benefit of Web API is of course that there are more tools, and extensions being developed by third party developers. There are several challenges in developing APIs that third parties will consume. The two key elements outside the usual development tasks, is the documentation of those APIs, including an API “Explorer” which allows developers to test out the APIs from a sandbox application.

The second major task you have to complete is the provision of SDKs in different languages. For most developers this is a tall task. They struggle to provide SDKs in any other language than the one they are used to working in. Thus, APIs built in Java are unlikely to have a Ruby SDK available.

API Explorer’s using Swagger

Swagger is an awesome and increasingly standard tool for offering developers the ability to try out your API without actually building anything. Using an API explorer they can authenticate using their issued credentials, and then execute REST calls using a web based tool.

Configuring Swagge for ASP.NET Web API just got way easier. Using Swashbuckle you can simply add a Nuget package, apply some configuration and start offering an API explorer in a few minutes. For more information please visit Swashbuckle.

SDKs using AutoRest

Building SDKs in different languages used to be hard, really hard. AutoRest makes it easy. AutoRest uses Swagger extensions to “read” your API definitions and then builds SDKs automatically from those definintions. The following languages/platforms are currently supported:

  1. .NET
  2. Mono
  3. Node.js
  4. Java
  5. Ruby

The AutoRest source code and documentation can be found on GitHub.

 

 

IFTTT.com recipe fails with WordPress recipe

I use Pocket as a personal bookmarking service. Using IFTTT.com I can use a recipe that monitors my Pocket feed and then sends new posts to my WordPress blog.

Recently though, this stopped working. The WordPress channel needed reconnecting, and the error I received every time I tried to connect was:

Unable to verify WordPress credentials. Please try again.

Thinking it was one of the security plugins I had used in WordPress, I switched them all off. The error remained. I had been doing some HTTPS redirection to make sure my site in always in HTTPS, so I switched that off too. Still no joy.

Finally I remembered that my site is protected by Cloudflare. When I ‘paused’ Cloudflare, the recipe worked.

My assumption was that Cloudflare was blocking IFTTT requests, assuming that they were attacks on my WordPress installation, but I couldn’t see any logs in the firewall logs in my Cloudflare account.

After wondering around in the Cloudflare settings, I turned items on and off to see if they would make a difference.

It turns out that there is one setting that can cause and therefore fix this problem!

I had a ‘Page Rule’ to force HTTPS always. IFTTT appears to assume HTTP and doesn’t support HTTPS! Bad IFTTT sending my blog logins over HTTP.