NServiceBus, Azure Service Bus, messages vanishing and not getting consumed

Question

I have two cloud service worker roles hosted in Azure, one which consumes messages using NServiceBus (Azure Service Bus transport) and another which produces them.

Yesterday, I deployed a new version of the producer worker role while there was still a quantity of messages in the queue, because we were working through some high volume that was left over from the morning. When the producer started, it appears to have emptied (or perhaps recreated) the queue, and a number of important production messages were lost. It seems strange, but the log show that at approximately the time the producer role started, no further messages were processed by the consumer, and we know for certain there were a few hundred in there waiting.

Is it possible that starting a message producer would re-create or empty a destination queue? If so, how can I configure NServiceBus to never do this?

Thanks.

Answer 1

No, NServiceBus never deletes a queue, not even a source queue, feel free to search the codebase at https://github.com/Particular/NServiceBus.AzureServiceBus/tree/master/src and you'll see that only subscriptions on topics can be deleted (when you unsubscribe)

However a consumer can opt in to purge the queue on startup, has it been configured that way (it's an opt in, not the default) You can scratch this, purge is not supported by the azure servicebus transport

Could something else, like a diagnostics or management tool, have read and deleted the messages from the queue maybe?

Answer 2

After weeks of searching, I finally have the answer. They were not deleted, they were moved into the dead letter queue. At the time, I did not even know how to look in there, it was only poking around with Azure Management Studio that I found them. It had nothing to do with the producer app being deployed - this was a red-herring.

After searching on why messages would end up there, I found this which explained the problem and solution. After adjusting the LockDuration and MaxDeliveryCount settings on the queue, the problem seems to have gone away.