Is it possible to determine whether a message is locked before attempting to receive it

Question

I am using peek-lock to receive messages using version 7.16.1 of the Azure.Messaging.ServiceBus SDK.

I am checking for active messages on a queue using the ServiceBusAdministrationClient class. The active message count does not consider locks, e.g. it may not be possible to receive an active message because it could be locked.

Given that the ServiceBusReceiver.ReceiveMessageAsync method works by polling the queue until either a message can be received or until the value of the maxWaitTime parameter has been exceeded, I would rather not attempt to receive a message unless I know that it is not locked.

I have tried calling ServiceBusReceiver.PeekMessageAsync to check the lock before calling ServiceBusReceiver.ReceiveMessageAsync, however, this does not seem to be reliable - sometimes the LockedUntil property of a message that I know is locked is set to the default value and other times it seems to reflect a previous lock that has since expired. I wonder if this is a bug in Service Bus or the SDK or if it's simply not something that can be relied upon when peeking messages.

Answer 1

There is no supported and reliable way to determine if a message is locked before attempting to receive. Any result that was calculated here would be point-in-time and potentially wrong the moment the calculation completed; the only reliable way is to attempt to acquire the lock.

Have you considered using a nominal value for maxWaitTime that would be just a bit above the time needed to accommodate the network transfer of your expected message size? This would generally be faster and more accurate than making multiple calls. In the scenario where a connection/link/auth need to be established, those are still governed by the TryTimeout of the retry policy and do not need to be accounted for in maxWaitTime.

A couple of notes:

• The Service Bus SDK does not calculate or modify the LockedUntil time; any value there comes directly from the service.

• Not relevant to the question, but potentially of interest for some - the Service Bus client does not poll. The attempt to receive a message is a single AMQP operation where the client signals the service and then waits for a message to stream in. The client gives up and cancels after maxWaitTime.

• If you'd like to suggest service features around this, your best bet would be the Service Bus forum of the Azure Feedback site.