How to get queue depth/length of azure queues when it exceeds int.MaxValue?

Question

Currently we use QueueProperties.ApproximateMessagesCount to get the queue depth. Problem is the property is of type "int" and our queues can exceed int's max value. We rely on queue depth for important infrastructural/operational decisions. Is there a way to get exact queue depth (preferably long or ulong)?

Answer 1

Hello Sreekara Yachamaneni,

Thank you for posting your query here!

Adding on to the previous response, the ApproximateMessagesCount property of the QueueProperties class in Azure Storage Queues is indeed of type int. This means it can hold a maximum value of 2,147,483,647 (int.MaxValue), and it cannot be directly used to get the queue depth if it exceeds this value.

https://learn.microsoft.com/en-us/dotnet/api/azure.storage.queues.models.queueproperties.approximatemessagescount?view=azure-dotnet

Unfortunately, Azure Storage Queues does not provide a built-in way to get the exact queue depth as a long or ulong.

Having more than 2 billion messages in a single queue is quite unusual and could indicate a need for a different architectural approach. For instance, partitioning the data across multiple queues.

Please note that Azure queues are designed to handle a large number of messages but having billions of messages in a queue could potentially lead to other issues, such as increased latency or difficulties in managing and processing the messages efficiently.

I hope this helps! Please let me know if the issue persists or if you have any other questions.

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

I don't use this API but a quick look at the underlying API call involved indicates it comes from the x-ms-approximate-messages-count HTTP header. That value is limited to an int32 so if it is larger than that then you wouldn't be able to tell.

If there is another way then I don't know what that would be. Of course I would question why you would have more than 2 billion messages in the queue at any one time anyway. I know Azure queues can handle millions of messages in the queue but billions seem like a stretch.