We Keep Coding

Azure Service Bus scheduled message arriving too late

I'm using ASB Topics. I'm connecting the service by using Microsoft .NET ServiceBus nuget (namespace Microsoft.Azure.ServiceBus.Core)
When a message arrive, my consumer either handles it and release the message or resending it to the topic with a delay.
The problem is that when the delay is less than 15 seconds, sometimes the message only arrive after 15 seconds.
e.g setting the delay to 3s or 10s usually works fine, but some of the messages arrive only after 15s (in both 3s or 10s cases).
When setting the delay to 20 seconds it works just fine with no exceptions.
It's for sure not load on the consumer because in some cases it was idle during the wait time.
I tried using prefetchCount but it had no effect.
I wanted to track the scheduled message in Azure UI but it seems that this option available for queues (not topics) only.
Any idea why is that happening and what can I do? thanks!

I'm using premium tier, my receiver runs in azure k8s. i'm quite sure
this number 15s is defined somewhere to delay messages in certain
cases. was wondering if someone knows about this.
You can queue or subject messages for later processing; for example, you can plan a job to be ready for processing by a system at a specific time. This functionality allows for the creation of a dependable distributed time-based scheduler.
Scheduled messages do not appear in the queue until the enqueue time has passed. Scheduled messages can be cancelled before that time. The communication is deleted when you cancel it.
You can use any of our clients to schedule messages in one of two ways:
Use the standard send API, but before sending, set the ScheduledEnqueueTimeUtc property on the message.
Pass both the standard message and the planned time to the schedule message API. This will return the SequenceNumber of the planned message, which you can use to cancel it later if necessary.
For more information please refer the below links:
MICROSOFT DOCUMENTATION:- Scheduled messages & Best Practices for performance improvements using Service Bus Messaging

Azure queue trigger vs service bus queue trigger, which one do I need?

I'm trying to understand the difference between a queue trigger and a service bus queue trigger and which one I need!
I have a asp.net mvc site that is for creating and scheduling classes, which will be represented as a row in a db table. When a class is over I want to send an email to all students asking them to rate their teacher
As far as I'm aware the best way to do this is to create a Azure function that will create and send the emails, but where I'm lost is how to trigger that function at a specific date and time?
Do I use a queue trigger or a service bus queue trigger? What's the difference between the two and which one would be the best for my scenario?
I need to be able to cancel the message in the queue if the class is canceled.

If cancelling scheduled messages is a hard requirement, only Service Bus allows doing that, see this blog.
However, it might be more practical to just add a check whether the class was cancelled at the beginning of your Azure Function, and quit if so.
For the rest of your scenarios, the services will both fit.
Generally, Service Bus has more advanced capabilities and guarantees, but costs more money if you send lots of messages. I usually pick Storage Queues unless I need any of those more advanced features.

Performing tasks at different times for different users after subscriptions

So here is the problem statement. I have a service which services mobile devices. Each user on the trigger of an event sends message to the service to register itself. After which the service performs a particular set of tasks at regular intervals(say 5 min) from the time of registration. So the execution time will be different for each user based on registration time.
I Implemented this using threads and Timers, it worked to an extent but as the users increased, the threads are killed and the tasks are not completed. Also this service is hosted on azure. I have created a WCF service with WebHtpp binding which accepts and returns JSON data.
Web jobs are a suggestion given to me. But since the execution times vary I am unable to use that as well. Is it even possible to perform such a task using C# and asp.net or am i going i the wrong direction entirely.

You need to identify where's the bottleneck that stops your threads before completion.
I would solve this using another approach: every new user, put a message in a queue, and create one Azure Function to dequeue the message and perform the logic of your service. This way your application will scale better, and you'll save money with the serverless approach.

How to enable reminders from an Azure based MVC application?

When a manager creates a task and sets the activation date in the future, it's supposed to be stored in the DB. No message is being dispatched out to the regarded workers, until a day or two before it's due. When the time's approaching, an email's being sent out to the subordinates.
Previously I've resolved that using a locally run Windows Service that scheduled the messaging. However, as I'm implementing something similar in the Azure, I'm not sure how to resolve it (other than actually hosting my own Windows Server in the cloud, of course, but kind of defeats the whole point).
Since my MVC application is strictly event driven, I've browsed around in the Azure portal to find a utility to schedule or postpone a method being invoked. No luck. So at the moment, all the emails are dispensed immediately and the scheduling is performed by keeping the message in the inbox until it's time (or manually setting up an appointment).
How should I approach the issue?

Other possible solution is to use Queueing mechanism. You can use Azure Storage Queues or Service Bus Queues.
The way it would work is when a task is created and saved in the database, you will write a message in a queue. This message will contain details about the task (may be a task id). However that message will be invisible by default and will only become visible after certain amount of time (you will calculate this period based on when you would need to send out the email). When the visibility timeout period expires, the message will become available to be consumed in the queue. Then you will have a WebJob with a Queue trigger (i.e. the WebJob will become alive when there's a message in the queue). In your WebJob code, you will fetch the task information from the database and send the notification to concerned person.
If you're using Azure Storage Queue, the property you would be interested in is InitialVisibilityTimeout. Please see this thread for more details: Azure storage queue message (show at specific time).
If you're using Azure Service Bus Queue, the property you would be interested in is BrokeredMessage.ScheduledEnqueueTimeUtc. You can read more about this property here: https://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.scheduledenqueuetimeutc.aspx.

One solution to run background tasks is to use Web Jobs. Web Jobs can run on a schedule (let's say once per day), manually or triggered by a message in a queue.

You can use Azure WebJobs. Basically, create a WebJob and schedule it to regularly check the data in your database for upcoming tasks and then notify people.

how do I filter Azure Service Bus Queue messages based on a message property?

I am using Azure Service Bus Queue to send emails out from my app. I have many different customers that send out emails via my app and each message gets a property that identifies that customer: CustomerID
I need to write an admin area for my customers to look at the pending message in the queue and more importantly see the deadletter queue. I do not want them to see everyones deadletters so I want to filter the messages based on the property CompanyID.
How do I accomplish this?
I read about topics and subscriptions but I add 10+ customers a week at least and this would not be a reasonable solution for me.

Queues do not support Filtering. You can write admin clients that get all messages and filter on the client end but consider Topics/Subscriptions because you can easily add up to 2000 Subscriptions per Topic and then filter messages in these by Customer etc. For things that you want to Query repeatedly on an approach as the one mentioned above, where you have a daemon parse the queue and update a table and then each customer runs queries on that status table would work better.

Queues are generally not a good fit for querying and advanced filtering scenarios. Peeking through a large queue when a customer checks for status would defeat the whole purpose of using a service bus.
My suggestion is to store the status of started tasks in Azure table storage. Once worker role processes or fails processing a message in the queue, it could simply update the status in the table storage.

You may use a polling mechanism utilizing receiveMessages() API in PEEK_LOCK mode in order to achieve filtering over queues and maintain a subscription to a flux stream of messages that pass your filter.
I have attempted to write a sample implementation in this project - Find GitHub Repo Here
Also, you can have a look at this article to understand its usage and scope.