CODEWITHSUNDEEP
azuresleepazure-worker-rolesthread-sleep
dumbledad
dumbledad

Reputation: 17527

Correct code pattern for recurrent events in Azure worker roles with sizable delays between each event

I have an Azure worker role whose job is to periodically run some code against a SQL Azure database. Here's my current code:

const int oneHour = 216000000; // milliseconds

while (true)
{
    var numConversions = SaveSeedsToSQL.ConvertRemainingPotentialQueryURLsToSeeds();
    SaveLogEntryToSQL.Save(new LogEntry { Count = numConversions });
    Thread.Sleep(oneHour);
}

Is Thread.Sleep(216000000) the best way of programming such regular but infrequent events or is there some kind of wake-up-and-run-again mechanism for Azure worker roles that I should be utilizing?

Upvotes: 1

Views: 357

Answers (1)

dunnry
dunnry

Reputation: 6868

This code works of course, but there are some problems:

  1. You can fail somewhere and this schedule gets all thrown off. That is important if you must actually do it at a specific time.
  2. There is no concurrency control here. If you want something only done once, you need a mechanism such that a single instance will perform the work and the other instances won't.

There are a few solutions to this problem:

  • Run the Windows Scheduler on the role (built in). That solves problem 1, but not 2.
  • Run Quartz.NET and schedule things. That solves #1 and depending on how you do it, also #2.
  • Use future scheduled queue messages in either Service Bus or Windows Azure queues. That solves both.

The first two options work with caveats, so I think the last option deserves more attention. You can simply create a message(s) that your role(s) will understand and post it to the queue. Once the time comes, it becomes visible and your normally polling roles will see it and can work on it. The benefit here is that it is both time accurate as well as a single instance operates on it since it is a queue message. When completed with the work, you can have the instance schedule the next one and post it to the queue. We use this technique all the time. You only have to be careful that if for some reason your role fails before scheduling the next one, the whole system kinda fails. You should have some sanity checks and safeguards there.

Upvotes: 3

Related Questions