Polling an Azure Service Bus
Question
Monday, January 23, 2017 3:00 PM
Hi,
I am looking at whether to use an Azure Service Bus Topic as part of a solution.
We need the polling of the queue to be real time but the best we can get is once a second. At once a second the cost of this however mounts up.
At 0.0006 an action
(1 poll/sec) * (60 secs / min) * (60 min/hour) * (24hrs /day) * (30 days) = 2,592,000 triggers
2,592,000 * £0.0006 = £1,555.20
I found the post below
https://brentdacodemonkey.wordpress.com/2016/09/29/azure-logic-apps-functions-and-service-bus/
which indicates that "the workflow is not actually running at 30 second intervals, but instead starts polling the queue and waits for that to time out, then it’ll wait 30 seconds and poll again"
I have done some tests and haven't found this to be the case and that it is polling every 30 seconds. Which is not responsive enough for our criteria.
Has anyone else any experience with this connector? I cannot justify the £1555.20 cost but the queue would make for a more elegant solution.
Many Thanks
John
All replies (5)
Tuesday, January 24, 2017 1:11 AM ✅Answered
Hi John,
According to the product team, the implementation uses a long poll with a time out of 30 seconds, so my understanding is that, to get it near real time, you should have your polling running at 30 seconds interval, which is when the previous poll times out. Still not ideal, but is quite a difference in price - 86+K actions related to trigger, compared to 2+M.
Did you try configuring it that way to see if that works for your scenario?
Cheers, Wagner.
Tuesday, January 24, 2017 2:20 AM
What is the business case you are working with ?
Might be a good Integration design consideration can help you . As of my side i use service bus to have asynchronous messaging pattern working and for synchronous i use different approach.
If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply
Tuesday, January 24, 2017 8:42 AM
Hi Wagner,
Yes that seems to work and make the queue / logic app more responsive.
Even polling every 30 seconds is quite expensive though at 86K actions (£51.84) .
Thanks Again for your help.
John
Tuesday, January 24, 2017 8:53 AM
Hi Abhishek,
I wanted to try and use the peek lock action to retrieve the message, then connect to Dynamics CRM, then remove the message off the queue if successful. That way the message would be left on the queue if there was an error and retried when CRM was available.
Whilst passing data into CRM does not have to be 'real time'. I would have expected it to be as close as possible (obviously dependant on number of messages on the queue) whilst retrieving messages off a queue for less money.
Having a 5 minute polling time, for example to keep costs does not seem responsive enough.
Many Thanks
John
Wednesday, January 25, 2017 1:52 AM
Hi John,
Now that we know that the long polling works, then you can plan a bit better the responsiveness of your trigger, based on price. For example, is a potential 30 sec delay acceptable, and mainly, worth GBP 25.00 less on the bill?
I'm assuming that since you are using topics, that you might end up having multiple subscriptions associated to the same topic? So Another consideration would be what kind of latency you should apply to each individual subscription.
But all in all, it was good to know that the info was useful. Not fired triggers was one of my beefs with the model too, but I can see that the product team is trying to minimize that as much as possible converting poll to push where possible, or introducing the concepts of long poll (like in this case) to make it a bit more reasonable.
Cheers, Wagner.