6

I am encountering an odd problem. I have a cloud service A that puts messages into a service bus queue for another cloud service B to read. Cloud service B can take about a second to process what it needs to do, then it puts a message back into a queue for cloud service A. When cloud service B does this it uses the ScheduledEnqueueTimeUtc to put a delay of around 1 - 10 seconds on the message.

Last Friday the azure outage brought this application down completely. When I brought it back online, ScheduledEnqueueTimeUtc is always causing a delay of at least 10 seconds. For instance, I generate a datetime that is between 1 and 10 seconds in the future. I set that as the ScheduledEnqueueTimeUtc and I also put that time as a property on the message I am sending, I compare that datetime property to the EnqueuedTimeUtc property of the message when I receive it back in cloud service A. These 2 times should be pretty close together, and that is the way it has been working for months up until last Friday.

So now cloud service B is saying it put this message into the queue in 1 second. Cloud Service A says it didn't get into the queue for 12-14 seconds. I am using async methods when putting messages into queues. There is no delay if I do not use ScheduledEnqueueTimeUtc, the times match up close enough when I look at them back in cloud service A. But if I set ScheduledEnqueueTimeUtc even 1 second in the future it seems to not show up in the queue for 12-14 seconds.

I am working around this now by using quartz.net to schedule messages instead of setting the ScheduledEnqueueTimeUtc property. But it just seems really odd that this started happening.

Brad Johnson
  • 91
  • 1
  • 7

2 Answers2

7

From ScheduledEnqueueTimeUtc Property's documentation:

"Message enquing time does not mean that the message will be sent at the same time. It will get enqueued, but the actual sending time depends on the queue's workload and its state."

That property causes the message not to be delivered immediatelly. It won't be delivered before the set time, but there is not assurance that it will be delivered exactly at that time.

If you need high resolution scheduling, Quartz may be an option. You might also evaluate the new job scheduler that is part of the Mobile Services preview.

Fernando Correia
  • 21,803
  • 13
  • 83
  • 116
  • 1
    Thanks, I did read that in the documentation. But I guess it just wasn't as clear as what you are saying and the fact that it just started happening threw me off. I guess I would have ran into this sooner or later. I need timing to be as acurate as possible in this application so it appears ScheduledEnqueueTimeUtc is out. Thanks! – Brad Johnson Mar 01 '13 at 18:02
  • `That property causes the message not to be delivered immediately` What does that mean? Will the message be sent to Azure, but not added to the queue until that time is reached or does it wait in the client application which will send it at that time? – Karl Gjertsen Jul 11 '16 at 14:54
3

There was a recent regression in the ShcheduledEnqueueTimeUtc functionality that would in some edge cases cause the behavior you saw above. This will be fixed in the next couple days and you should see the expected/original behavior.

Scheduled messages can have some lag based on how busy the Queue is but is fine to use in the scenario you mention above. Any regression in functionality that affects your application can be raised as a support ticket with Azure: http://www.windowsazure.com/en-us/support/contact/

Abhishek Lal
  • 3,233
  • 1
  • 17
  • 16