CODEWITHSUNDEEP
azureservicebusservicebusazure-logic-appsazure-servicebus-queues
jcools85
jcools85

Reputation: 236

Logic Apps: ServiceBus trigger with concurrency control causes peek-lock timeouts

Since a few days I see some "new" behaviour when using the ServiceBus trigger in Logic Apps in combination with the "Concurrency control" feature. I have a polling trigger checking a queue every 5 minutes. And configured the concurrency control to max 5 instances, to not overload my backend database.

In the past when I put 40 messages on the queue, it would spin up 5 instances.. when the polling interval had passed, 3 instances were still running... the trigger then spun up 2 more instances to bring the total running instances back to my configured threshold of 5. I was a happy customer :)

Now I see that the trigger instantly creates 40 instances. 5 of them running, the other 35 in the "waiting" state. When an instance is done processing, one of the waiting instances starts it's work. Sounds good, don't you think? Not in all scenarios..

enter image description here

When using the Peek-lock mechanism the timeout starts counting when the "waiting" instance is started.. If it has to wait longer than 5 minutes (lock timeout max) the lock is expired. This causes the message to become available again on the queue, resulting in a new "waiting" instance being started for the same message. So in the end, I end up with a lot of unnecessary duplicate processing, and even messages being deadlettered because they reached the maxDeliveryCount limit.

Can't seem to find any information on this change in polling behaviour? Anyone with a workaround for the Peek-lock problem besides using Auto-complete?

UPDATE 07/08/2018:

MSFT Logic App Product Team confirmed that this is the new implementation to enable concurrency control for SplitOn triggers. Once you enable SplitOn on your Logic App you will get this behaviour. Even when you disable SplitOn again, the behaviour stays that way. to "reset" your Logic App you will have to completely delete the resource and redeploy it.

Upvotes: 1

Views: 2359

Answers (2)

jcools85
jcools85

Reputation: 236

MSFT Logic App Product Team confirmed that this is the new implementation to enable concurrency control for SplitOn triggers. Once you enable SplitOn on your Logic App you will get this new behaviour. Even when you disable SplitOn again, the behaviour stays that way. To "reset" your Logic App you will have to completely delete the resource and redeploy it.

If the "waiting runs" implementation suits your scenario, but you still wish to control the number of instances that are started/waiting with each trigger run, there is a setting that you can use to control the maximum “waitingRuns”. Unfortunately, this is not enabled in the UI yet so you need to go to the codeview. At the moment maximumWaitingRuns can't be set lower than 1.

maximumWaitingRuns

Upvotes: 3

Arunprabhu
Arunprabhu

Reputation: 1494

It sounds like a real problem. As the maximum value for lock duration is 5 minutes, you have no other option but to use Auto-complete.

My suggestion is to have Topic with two Subscriptions or a Duplicate Queue.

Topic Subscription - message will be sent to both Subscriptions, where you can use one subscription for Logic app Auto-complete and another Subscription for tracking the messages. As both Subscriptions will have the same messages, there will not be any duplication or missing messages.

Duplicate Queue - You can make the Logic app auto completes the message and froward it to a second Queue, where you can track the messages.

Upvotes: 0

Related Questions