You are developing a .NET background worker service that processes media rendering tasks from an Azure Service Bus queue. The rendering tasks are computationally intensive and take between 2 to 4 minutes to complete. The queue's default lock duration is set to 30 seconds. You must ensure that tasks are not processed by multiple workers concurrently, and if a worker crashes during processing, the task must be returned to the queue without message loss. Which configuration strategy should you implement?
- Initialize the ServiceBusProcessor in PeekLock mode, and set the MaxAutoLockRenewalDuration property in ServiceBusProcessorOptions to 5 minutes.Answer
- BInitialize the ServiceBusProcessor in ReceiveAndDelete mode to instantly remove the message from the queue, preventing lock expiration issues.
- CGenerate a Service Bus namespace Shared Access Signature (SAS) token with Manage permissions to allow the background worker code to dynamically update the queue's default lock duration property during message execution.
- DConfigure the background worker to authenticate using a user-assigned managed identity instead of a system-assigned managed identity to automatically increase the default lock duration to 5 minutes.
Answer
Initialize the ServiceBusProcessor in PeekLock mode, and set the MaxAutoLockRenewalDuration property in ServiceBusProcessorOptions to 5 minutes.
The correct answer demonstrates how to handle long-running message processing safely in Azure Service Bus. By retaining PeekLock mode, messages are protected from loss if the worker fails. Configuring the MaxAutoLockRenewalDuration property in the ServiceBusProcessorOptions allows the background SDK client to renew the lock periodically up to the specified limit (5 minutes), preventing other workers from picking up the message while it is still being processed.
Step-by-Step Solution
Key Concept
Azure Service Bus message locking mechanics, receiver modes, and automatic lock renewal properties inside the .NET SDK.
Estimated Time:2m 0s