Microsoft Azure Service Bus超时例外

时间:2015-05-28 14:30:56

标签: c# azure timeout azureservicebus

我们有一个在Microsoft Azure云平台上运行的应用程序。某些组件之间的通信使用Service Bus进行。一切都运行良好,直到最近我们才开始获得以下类型的超时异常:

致电QueueClient x.Send(...)

  

在[0]处重新抛出异常:at   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)at   Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult的   结果)

致电NamespaceManager x.GetQueue(...)

  

PROGRESS队列处理失败。 System.TimeoutException:请求   在60000毫秒后超时。顺利完成   请求无法确定。应该进行额外的查询   确定操作是否成功。   TrackingId:bdffb6bd-5367-4573-aaa3-8ea9a03f5a2b,时间戳:2015年5月28日   上午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)at   Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult的   结果)

致电NamespaceManager x.SubscriptionExists(...)

  

执行定期工作的异常:System.TimeoutException:请求   在00:10:00毫秒后超时。顺利完成   请求无法确定。应该进行其他查询   确定操作是否成功。服务器堆栈   trace:在[0]处重新抛出异常:at   Microsoft.ServiceBus.Common.AsyncResult.End [TAsyncResult](IAsyncResult的   结果)在   Microsoft.ServiceBus.NamespaceManager.OnEndSubscriptionExists(IAsyncResult的   结果)在   Microsoft.ServiceBus.NamespaceManager.SubscriptionExists(字符串   topicPath,String name)...

致电QueueClient x.Receive(...)

  

PROGRESS队列处理失败。   Microsoft.ServiceBus.Messaging.MessagingCommunicationException:错误   在与Service Bus通信期间。检查连接   信息,然后重试。 --->   System.ServiceModel.CommunicationObjectFaultedException:Internal   服务器错误:服务器未提供有意义的回复;这个   可能是由于过早的会话关闭造成的。   TrackingId:04ba0220-0350-4806-9c65-c2bba9671054,时间戳:28.05.2015   13:00:55服务器堆栈跟踪:在[0]处重新抛出异常:at   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)at   Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult的   结果)......。

例外与ServiceBus明显相关,并且它们是非确定性的。抛出它们的函数,例如SendGetQueueSubscriptionExists,每分钟调用次数不超过100-120次。我们在代码中没有改变任何内容,并且增加超时值(即使是非常高的值,比如10分钟)也无济于事。此外,我们不相信这是一些与网络相关的问题(在我们这边),因为当应用程序从不同的地方运行时会发生同样的错误。

最近有没有其他人遇到过这种例外情况?微软是否存在问题,或者我们遗漏了什么?

2 个答案:

答案 0 :(得分:1)

几个星期前,我们的服务总线应用已经投入生产了好几个月,突然出现了无法解释的时间问题。我们继续工作,但每次通话时间通常为100-200毫秒,每次通话需要10秒以上。这持续了几个星期,我花了大部分时间试图弄清楚发生了什么,从未做过,因为问题突然消失了。

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

答案 1 :(得分:1)

当我的运行代码开始生成Timeout异常时,我遇到了类似的问题。经研究发现防火墙阻塞了用于通信的端口。但是,80和443端口仍处于打开状态。因此,添加以下代码行对我有用:

ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https;