我遇到订阅超时的问题。我在命名空间管理器上采用了指数重试策略(maxBackoff 30 秒)，这有助于缓解 QueueExists() 和 TopicExists() 的超时问题。然而，我记录的 95% 以上的错误都与 GetSubscription() 和 SubscriptionExists() 有关。我确实有很多队列(超过 1000 个)、主题(超过 1000 个)和订阅者(超过 1000 个)。没有哪个主题拥有超过 700 名订阅者，这使我们轻松远离每个主题 2000 名订阅者的限制。如有任何帮助，我们将不胜感激!
GetSubscription() 的经过清理的错误段:
请求在 60000 毫秒后超时。无法确定请求是否成功完成。应进行其他查询以确定操作是否成功。 TrackingId:[guid，有意删除]、TimeStamp:[日期时间，有意删除] 服务器堆栈跟踪:在 [0] 处重新抛出异常: 在 Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult 结果)在 Microsoft。 ServiceBus.NamespaceManager.OnEndGetSubscription(IAsyncResult result) 位于 Microsoft.ServiceBus.NamespaceManager.GetSubscription(String topicPath, String name) 位于 [剩余部分有意删除]
SubscriptionExists() 的经过清理的错误段:
请求在 60000 毫秒后超时。无法确定请求是否成功完成。应进行其他查询以确定操作是否成功。 TrackingId:[guid，有意删除]、TimeStamp:[日期时间，有意删除] 服务器堆栈跟踪:在 [0] 处重新抛出异常: 在 Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult 结果)在 Microsoft。 ServiceBus.NamespaceManager.OnEndSubscriptionExists(IAsyncResult result) 位于 Microsoft.ServiceBus.NamespaceManager.SubscriptionExists(String topicPath, String name) 位于 [剩余部分有意删除]
我希望对使用堆栈跟踪中提供的跟踪信息的任何机制有所启发。 谢谢!
最佳答案
我了解到应该避免使用 SubscriptionExists()。首选是执行 NamespaceManager.GetSubscription() 调用并捕获 MessagingEntityNotFoundException，以便将其丢弃。
关于c# - 如何影响 Azure C# 中 GetSubscription() 和 SubscriptionExists() 的重试策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32609888/