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…

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.


Tracking JavaScript errors in Google Analytics

For hackers:

For Google Analytics users:

Analytics will allow you to filter by OS, browser, and all the other environment data it already captures. And nice graphs as a bonus 🙂