Azure服务总线队列ScheduledEnqueueTimeUtc延迟

Question

我遇到一个奇怪的问题。我有一个云服务A，它将消息放入服务总线队列中供其他云服务B读取。云服务B可以花费大约一秒来处理它需要做的事情，然后它将消息放回到云服务A的队列中。当云服务B这样做时，它使用ScheduledEnqueueTimeUtc来延迟大约1-10秒在消息上。

上周五蔚蓝的停电使这个应用程序完全失效。当我将它重新联机时，ScheduledEnqueueTimeUtc总是造成至少10秒的延迟。例如，我将来会生成1到10秒之间的日期时间。我将它设置为ScheduledEnqueueTimeUtc，并且将该时间作为属性发送给我要发送的消息，然后将该日期时间属性与消息的EnqueuedTimeUtc属性进行比较，当我将其返回到云服务A时。这两次应该很漂亮这是它直到上周五一直工作数月的方式。

因此，现在云服务B说它会在1秒内将此消息放入队列中。云服务A表示它没有进入队列12-14秒。将消息放入队列时，我使用异步方法。如果我不使用ScheduledEnqueueTimeUtc，则不会有任何延迟，当我在云服务A中查看它们时，时间匹配足够接近。但是，如果将来设置了ScheduledEnqueueTimeUtc甚至1秒，它似乎不会在队列中显示12 -14秒。

我现在正在通过使用quartz.net来安排消息而不是设置ScheduledEnqueueTimeUtc属性来解决此问题。但是这似乎很奇怪，这开始发生。

Answer 1

从ScheduledEnqueueTimeUtc Property's documentation：

“消息enquing时间并不意味着该消息将在同一时间发送它会得到排队，但实际的发送时间取决于队列的工作量，其状态”

该属性导致消息不立即传递。它不会在之前交付设定的时间，但不保证当时将交付确切。

如果您需要高分辨率调度，Quartz可能是一个选项。您也可以评估作为移动服务预览一部分的新job scheduler。

Answer 2

ShcheduledEnqueueTimeUtc功能最近出现了一些回退，在某些边缘情况下会导致您在上面看到的行为。这将在接下来的几天内解决，你应该看到预期/原始行为。

根据队列的繁忙程度，计划消息可能会有一些延迟，但在上面提到的场景中可以使用。任何影响您的应用程序的功能回归都可以作为Azure的支持票证提出：http://www.windowsazure.com/en-us/support/contact/