9
votes

I recently created some partitioned queues from where I send and receive all the time. They've run as non-partitioned in the past without any of my current issues.

The problem is, I have a constant number of messages in the queue that I can not receive. I always get nothing back when not sending any other messages to the queues but when I send messages to the queues I receive the new messages without a problem. The messages that are stuck in the queue are active messages, not dead lettered.

I'm suspecting they're stuck in a specific partition(s) but I don't know how to receive them.

Since I cannot receive these messages is there way to reset the ServiceBus Queue?

Any ideas?

Update:

The number is not constant but very slowly increasing. On our testing environment we receive little more than 2000 messages per hour and the queues, after being reset to 0 (zero) has received around 20 messages each in the last 12 hours. Those messages are just there but not receivable. At least not in the usual way.

The issue is only in two namespaces after they have been partitioned. The issue is not in our live environment where we don't use partitioned queues.

4
Did you depend on the namespaceManager.GetQueue().MessageCount ? --> if this is the way - can you browse the Q using Service Bus Explorer tool or using Api, when you observe that the Q is in Stuck state and Browse/peek the Top message and then Send another message and see if the Top msg is not changing. I am suspecting that it is Probably just a count problem. If that is the case - Disable and Enabling the Q will lead to resetting the NSMgr.GetQueue().MessageCount to the correct value.Sreeram Garlapati
@1of5om3 The messages showed up in both the portal and while browsing the queues through VS and programmatically. It would count up when sending messages to it and count down when receiving and deleting from it. We finally decided not to use it for now as it seems there might be a counter problem but we can't be sure. And you're right about the disabling/enabling as well.user2413912
@user2413912 Did you find any solution? Since I'm facing the same issue.user3012488

4 Answers

2
votes

I have seen a similar thing in our production env - maybe its the same behavior you are seeing. Using ServiceBusExplorer or something similar, check if the message's 'ContentType' = application/vnd.ms-servicebus-ping.

If so... this is a (Azure) system generated message to determine queue availability... as far as I know these messages are supposed to disappear after they are received... but mine do not either. The documentation from MS is sparse on this stuff...

In any case, if you make sure that this is the cause, you can at least rest assured that they are not YOUR messages that are stuck in ServiceBus purgatory. Hopefully MS fixes this soon...

0
votes

Check the lock duration of your queue. If the Messages had been received but not marked as Complete() they seem to be "stuck" (not receivable) until the lock releases the Message again.

0
votes

Found this question while looking into an issue with messages stuck in a topic subscription. Messages were visible in Azure Portal and Service Bus Explorer but not being picked up by my application using the RegisterMessageHandler function.

This was resolved after toggling the Topic state to Disabled and then back to Active. enter image description here

-1
votes

From Service Bus explorer you can check these messages and the state of them, they might be in deferred state. To know more about deferred state read this.

"When a queue or subscription client receives a message that it is willing to process, but for which processing is not currently possible due to special circumstances inside of the application, it has the option of "deferring" retrieval of the message to a later point. The message remains in the queue or subscription, but it is set aside."