This article is about optimizations when integrating the “When messages are available in a queue (peek-lock)” Logic App trigger with an Azure Service bus queue.
Under high load scenarios or business flows that takes from 1 to 5 minutes, stateful logic apps which are triggered by “When messages are available in a queue (peek-lock)” trigger, may need some adjustments for optimizing performance and avoiding degradation issues like the below mentioned:
{
"code": "ServiceProviderActionFailed",
"message": "The service provider action failed with error code 'BadRequest' and error message 'The lock supplied is invalid. Either the lock expired, or the message has already been removed from the queue. For more information please see https://aka.ms/ServiceBusExceptions . Reference:XXXXXXX, TrackingId:xxxxxxxxxxxx, SystemTracker:gi::xxxxxxxxxxxxx:amqps://xxxxxxxxx.servicebus.windows.net/-source(address:/queue,filter:[]), Timestamp:2024-05-30T00:48:25 (MessageLockLost). For troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.'."
}
This may be due the several reasons. Let’s explore 2 of them and understand how they can be solved.
- Lock duration (lockduration for more details) property of the service bus queue is set to 1 minute by default. However, our business flow can take longer. To solve this problem, we can increase it up to 5 minutes.
There are various ways to increase this value.
a. Existing queue through the Azure portal:
Go to the Service Bus namespace >> Entities >> Queues >> Your Queue >> Click “change” in the Message lock duration property and enter the new value and click “OK”
b. Existing queue through Azure PowerShell: we are not going deep into this. Please refer to the following article:
How to set LockDuration on an Azure ServiceBus queue with PowerShell | John Billiris (wordpress.com)
c. When creating a new queue:
Go to the Service Bus namespace >> Entities >> Queues >> “+ Queue” and set the lock duration to a value between 1 to 5 minutes. This will vary depending on your environmental requirements.
2. Other possible root cause could be that our logic app is reaching the PeekLock cache threshold which by default is 5000. This cache expiry duration is 30 minutes so this setting should be set around the number of messages your workflow expects in that time.
It is important to be aware that once the message is completed, the entry is removed from cache so typically it will not hit near the number of messages expected in 30 minutes.
Fixing it is easy, just set the ServiceProviders.ServiceBus.PeekLockTriggerContextCache.CacheCapacity appsetting to a bigger value and reboot the logic app. However, be aware that this will have a memory overhead in our Standard Plan (WS1/WS2/WS3) or ASE so it is important to be accurate when setting this value and have a realistic approach of the environment loads. It is a best practice to testing in non-productive environments before.
This is how it can be done by Azure Portal:
Go to Azure Portal >> Your Logic App >> Settings >> Environment Variables >> App Settings and then add ServiceProviders.ServiceBus.PeekLockTriggerContextCache.CacheCapacity = #yournewvalue (10000 for this case)
Microsoft
