Do Azure Service Bus Queues Receivers have a Timeout Limit?

Question

We are receiving a message from Azure Service Bus Queue. The receiver (message handler) on the queue, calls an Application Service, which updates a Million+ records in a SQL Database table, process takes more than 30 min.

Does Azure service bus queue have a timeout limit? Will this cause SQL Table process to stop updating rows?

https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-get-started-with-queues

The actual Service Bus Message queue which is being Sent is pretty small, its just a Year and ProductType. Then the app service method will take the two parameters, and update the whole sql table.

Azure Service Bus Queue Method ---> Service Bus Message Receives (Event Handler) ---> Calls App Service to Update SQL Table

Answer 1

Short Answer: In Peek-Lock receive mode max lock duration supported is 5 minutes.

Now the long answer :)

There are 2 modes of the Service Bus message receiver.

1. Peek-Lock Mode (non-destructive): This is default if you do not specify while creating QueueClient (the constructor has overload which accepts ReceiveMode). In this mode, receive locks/hides the message for the client for a period (called lock duration) which is a setting of the queue (you can check in Azure portal). Max supported value is 5 minutes. If your processing is not complete by then and you do not complete the message (CompleteAsync), the lock expires and the message reappears in the queue. For more details, refer https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-transfers-locks-settlement#peeklock

For long-running operation, one technique is to renew the lock with lesser interval than lock duration. In the example you are following, you can set MaxAutoRenewDuration property in MessageHandlerOptions which can automatically renew for you.

The other technique could be leveraging Message deferral feature where you start your processing on receive, but keep on deferring the message retrieval until your process is complete at which point you receive the message and complete. Slightly complex, but a smart way.

2. Receive and Delete Mode (destructive): In this mode, the message is deleted from the queue on receiving as the name suggests. So you can take as long as time for your processing. But problem is you have the risk of losing the message forever in case your client crashes in mid of processing.