sfeldman.NET

Using NServiceBus on Azure allows the best of two worlds – robust and reliable messaging framework on top of excellent Azure services. Azure services and any other cloud provider as well have strict capacity and quotas. For Azure transports NServiceBus is using, those are usually allowed maximum throughput, the total number of messages, the number of concurrent connections, etc. With Azure Storage Queues there’s an additional constraint that while is not significant on its own, does have a weight in a system: maximum message TTL is seven days only. Yes, yes, you’ve heard right. 7 days only. Almost as if someone at the storage team took the saying “a happy queue is an empty queue” and implemented maximum message TTL using that as a requirement. While it’s ok to have such a short message TTL for a message that is intended to be processed, for messages that are processed and need to be stored that could be an issue.

Azure Service Bus is one of the oldest cloud services on Azure. As any service living in the cloud, it grows, iterates, and changes. Among various features that the service has, there's one that could deserve a little more attention: paired namespaces.

In some cases, when a message should be abandoned, Azure Service Bus offers BrokeredMessage.Abandon() API. The message is abandoned immediately; delivery count is increased, and message re-appears on the broker. In case MaxDeliverCount is exceeded, the message is moved to the designated dead letter queue. Whenever a message is moved to a dead letter queue, it is stamped with two standard properties: DeadLetterReason and DeadLetterErrorDescription. Here's an example of how to get a message dead lettered and stamped with these two properties

When Marty went back to 1955, he had no idea how to make it back. Using Azure Service Bus BrokeredMessage property ScheduledEnqueueTimeUtc to schedule a message in the future would feel the same when the need to cancel the scheduled message would arise. Congratulations, you've scheduled a message. Sorry, there's no way to call it off until it happens. Gladly, the Doc (read ASB team) has introduced a new feature in the latest 3.3.1 version that allows to schedule a message and cancel it on demand, before becoming visible/available.

Coming from the world of web applications where configuration file update is a matter of dropping a new version of a web.config file into the application, Azure Service Fabric can be a new territory. Especially with its hard rule on versioning code, data, and config packages. The config package update is what I'd like to focus on in this post.