【问题标题】:Microsoft Azure Service Bus Timeout ExceptionsMicrosoft Azure 服务总线超时异常
【发布时间】:2015-08-11 03:18:07
【问题描述】:

我们有一个在 Microsoft Azure 云平台上运行的应用程序。一些组件之间的通信是使用服务总线进行的。一切正常,直到最近我们才开始出现以下类型的超时异常:

拨打QueueClient x.Send(...)

在 [0] 处重新抛出异常:在 Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult 结果)在 Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.DuplexCorrelationAsyncResult.End(IAsyncResult 结果)在 Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory `1.RequestSessionChannel.RequestAsyncResult.b__4(RequestAsyncResult thisPtr, IAsyncResult r) 在 Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult 结果)

拨打NamespaceManager x.GetQueue(...)

PROGRESS 队列处理失败。 System.TimeoutException:请求 60000 毫秒后超时。圆满完成 无法确定请求。应进行额外查询 判断操作是否成功。 TrackingId:bdffb6bd-5367-4573-aaa3-8ea9a03f5a2b,时间戳:5/28/2015 上午 8:39:46 ---> System.Net.WebException:请求被中止: 请求被取消。在 System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
在 Microsoft.ServiceBus.Messaging.ServiceBusResourceOperations.GetAsyncResult`1.b__49(GetAsyncResult`1 thisPtr, IAsyncResult r) 在 Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult 结果)

拨打NamespaceManager x.SubscriptionExists(...)

做周期性工作的异常:System.TimeoutException: The request 在 00:10:00 毫秒后超时。圆满完成 无法确定请求。应进行额外查询 判断操作是否成功。服务器堆栈 跟踪:在 [0] 处重新抛出异常:在 Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult 结果)在 Microsoft.ServiceBus.NamespaceManager.OnEndSubscriptionExists(IAsyncResult 结果)在 Microsoft.ServiceBus.NamespaceManager.SubscriptionExists(字符串 主题路径,字符串名称)...

拨打QueueClient x.Receive(...)

PROGRESS 队列处理失败。 Microsoft.ServiceBus.Messaging.MessagingCommunicationException:错误 在与服务总线通信期间。检查连接 信息,然后重试。 ---> System.ServiceModel.CommunicationObjectFaultedException:内部 服务器错误:服务器没有提供有意义的回复;这 可能是由于会话过早关闭造成的。 TrackingId:04ba0220-0350-4806-9c65-c2bba9671054,时间戳:28.05.2015 13:00:55 服务器堆栈跟踪:在 [0] 处重新抛出异常:在 Microsoft.ServiceBus.Common.ExceptionDispatcher.Throw(异常 例外)在 Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult 结果)在 Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.DuplexCorrelationAsyncResult.End(IAsyncResult 结果)在 Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.EndRequest(IAsyncResult 结果)在 Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory`1.RequestSessionChannel.RequestAsyncResult.b__4(RequestAsyncResult thisPtr, IAsyncResult r) 在 Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult 结果)……

异常显然与 ServiceBus 相关,并且它们是不确定的。抛出它们的函数,例如SendGetQueueSubscriptionExists,每分钟调用不超过 100-120 次。我们在代码中没有做任何更改,并且增加超时值(甚至是高得离谱的值,比如 10 分钟)也没有帮助。此外,我们不认为这是一些与网络相关的问题(在我们这边),因为当应用程序从不同的地方运行时会发生相同的错误。

最近有没有其他人遇到过这类异常?是微软方面有问题还是我们遗漏了什么?

【问题讨论】:

标签: c# azure timeout azureservicebus


【解决方案1】:

几周前,我们的 Service Bus 应用程序出现了突然且无法解释的时间问题,该应用程序已投入生产数月。我们的继续工作,但每隔几个电话就需要 10 多秒,而它们通常是 100-200 毫秒。这持续了几个星期,我花了大部分时间试图弄清楚发生了什么,但随着问题突然消失,我从来没有这样做过。

我们确实了解到,我们在同一数据中心和其他数据中心创建的新服务总线命名空间用于在问题发生时进行测试并没有出现同样的问题。服务总线小组没有提供任何帮助,只说响应时间不能保证只有 SLA。

【讨论】:

    【解决方案2】:

    当我的运行代码开始生成超时异常时,我遇到了类似的问题。经过研究发现防火墙阻止了用于通信的端口。但是,80 和 443 端口仍然开放。所以添加以下代码行对我有用:

    ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https;
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-02-25
      • 2015-06-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多