邮件被延迟到手动创建的天蓝色队列

手动创建的azure队列上出现了不同的行为，并且以编程方式创建了一个行为。邮件被延迟到手动创建的天蓝色队列

我有两个天青队列。一个是通过Azure门户（ARM）手动创建的，另一个是使用Azure SDK（2.9）NamespaceManager类从c＃程序创建的。

我没有问题使用QueueClient类（从创建队列的程序的相同或不同实例）向编程创建的队列发送消息。但是，如果我使用相同的代码将消息发送到手动创建的队列，那么消息不会通过，至少不是一开始;他们被严重拖延了。我还没有设法确定延迟，但至少几小时，可能几天。我还没有能够证明这些信息是否总是最终通过，或者是否有人遗失。我看不出可能解释不同行为的队列属性之间的任何显着差异。

一旦消息出现在队列中，就不会观察到进一步的延迟。

是否有任何原因可能会延迟手动创建的队列？

编辑： 进一步的调查显示，在一个完全新的区域中的消息到新的手动创建的队列中的新服务总线没有延迟，但消息发送到第二手动创建队列在该新的总线做。至少队列2上的消息尚未完成（几分钟）。时间会告诉他们是否事后露面。

来源

2017-09-10 andrea

这两个队列在同一个区域？你尝试过其他队列吗？如果您可以轻松地重现该行为，这听起来不正确。顺便说一下，2.9是旧的。有4.x –

所有的队列都在同一个服务总线和相同的区域。全部在英国西部。也许我应该尝试不同的地区，看看是否有区别？ – andrea

我有的版本是从这里的Visual Studio 2015 https://azure.microsoft.com/en-gb/downloads/ – andrea

命名空间应该允许多个实体。根据documentation，高达10,000。这个特定的命名空间有一些东西。您可以尝试删除并重新创建它。或者，您可以跟进Microsoft支持来调查发生的事情。这需要时间，如果您需要命名空间名称，请阻止您，直到调查结束。

来源

2017-09-11 12:50:38

我在发布时正在编辑问题。这看起来像是一个天蓝色的问题。然而，我现在在两个不同的区域有两个不同的命名空间，具有相同的行为。支持案例可能是要走的路。谢谢。 – andrea

这似乎是在azure门户中显示消息时的问题。这些消息实际上可以从SDK访问，即使它们没有出现在Azure门户中。

来源

2017-09-11 13:08:37 andrea

邮件被延迟到手动创建的天蓝色队列

回答

相关问题