sfeldman.NET

Testing code that involves queues always has some utility code that is responsible for test cleanup. The cleanup is often implemented as a queue purge operation. For example, MSMQ allows to delete all messages in a queue by calling a Purge() command on a queue.

How often do you write code and think about what will it look like the compiler is done with it? If you're like me, not often. But is it a good thing that over the time we've learned to trust unquestionably the compiler and blindly rely on it to do the job for us?

I was reading a question on StackOverflow where the requirement was to "Lock a Service-Bus Queue and prevent others from accessing it." Quite often when dealing with competing consumers and PeekLock mechanism it feels odd. What do you mean I'm in the middle of processing my message and it will re-appear on the queue?! Why do I need to worry about some LockDuration?! The answer is simple. The server allows the receiver to handle the message and completes it within LockDuration time. If the operation takes longer, the server will no longer respect the original lock token as it will be replaced by another receiver that got the message.

I tend to keep connection strings, security tokens, and other secrets in the environment variable. This is handy when you commit your code to a public repository and want to make sure that your storage account connection string is not shared worldwide. It's also convenient because all those variables can be accessed in almost any hosting environment (VM, Cloud Service, WebJob, Azure Function, you name it). The downside - getting to those environment variables fast to modify those.

Azure Service Bus still can't be created at the new portal, aka Ibiza. To create Azure Service Bus namespace and create entities, one has to do in manually at the old portal. That wouldn't be so bad, but the lack of controlling what Resource Group the new namespace will belong to is a slight impediment for those that like their resources to be at the right places.

Today have run into an interesting issue: a cloud service deployed with a 3rd party assembly version X was failing. The exception was indicating that version X-1 of the assembly was deployed. Looking at the project packages.config could see nothing but version X of the assembly. Quite a mystery.

Messaging is about small messages. You should keep your messages relatively small. If you have fat messages, you're doing it wrong. All valid statements, until you look closer at the Azure Service Bus Quotas information. The ones that are sometimes hard to digest would be:

When Azure Functions were announced at the Build2016 conference, I had to see what is it. Part of my curiosity was fueled by the same thought I had for WebJobs when those where announced first. To be more specific, an alternative hosting environment for NServiceBus in the Azure cloud. I'll share my personal conclusions in a little bit. However, first, what are Azure Functions?