命名空间超过Azure ServiceBus ConnectionsQuota

Question

我们在项目中使用Azure ServiceBus将消息传递到不同的组件。 目前，我们有7个主题，其中45个订阅。 最近，我们开始获取Microsoft.ServiceBus.Messaging.QuotaExceededException：名称空间的ConnectionsQuotaExceeded。

根据Azure ServiceBus配额和限制，每个名称空间的并发连接限制为1000。我们绝对不会超过200。有人遇到类似问题吗？

下面是堆栈跟踪：

Microsoft.ServiceBus.Messaging.QuotaExceededException：名称空间testtrlsb的ConnectionsQuotaExceeded。 d2759061-962d-436b-980d-1b901019d569_G51 ---> System.ServiceModel.FaultException 1[System.ServiceModel.ExceptionDetail]: ConnectionsQuotaExceeded for namespace testtrlsb. d2759061-962d-436b-980d-1b901019d569_G51Server stack trace: at Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.ThrowIfFaultMessage(Message wcfMessage) at Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.HandleMessageReceived(IAsyncResult result)Exception rethrown at[0]: at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.DuplexCorrelationAsyncResult.End(IAsyncResult result) at Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory 1[System.ServiceModel.ExceptionDetail]: ConnectionsQuotaExceeded for namespace testtrlsb. d2759061-962d-436b-980d-1b901019d569_G51Server stack trace: at Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.ThrowIfFaultMessage(Message wcfMessage) at Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.HandleMessageReceived(IAsyncResult result)Exception rethrown at[0]: at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.Sbmp.DuplexRequestBindingElement.DuplexRequestSessionChannel.DuplexCorrelationAsyncResult.End(IAsyncResult result) at Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory 1.RequestSessionChannel.RequestAsyncResult.b__4（RequestAsyncResult thisPtr，IAsyncResult r）在Microsoft.ServiceBus.Messaging.IteratorAsyncResult 1.StepCallback(IAsyncResult result)Exception rethrown at[1]: at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory 1.StepCallback(IAsyncResult result)Exception rethrown at[1]: at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory 1.RequestSessionChannel.EndRequest（IAsyncResult的结果）在Microsoft.ServiceBus.Messaging.Sbmp.RedirectBindingElement.RedirectContainerChannelFactory 1.RedirectContainerSessionChannel.RequestAsyncResult.<>c__DisplayClass17.<GetAsyncSteps>b__a(RequestAsyncResult thisPtr, IAsyncResult r) at Microsoft.ServiceBus.Messaging.IteratorAsyncResult 1.StepCallback（IAsyncResult result）在[2]处引发异常：在Microsoft.ServiceBus.Messaging.Sbmp.RedirectBindingElement.RedirectContainerChannelFactory的Microsoft.ServiceBus.Common.AsyncResult.End [TAsyncResult]（IAsyncResult result） 1.RedirectContainerSessionChannel.EndRequest(IAsyncResult result) at Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory 1.RequestSessionChannel.RequestAsyncResult.b__4（RequestAsyncResult thisPtr，IAsyncResult的r）是Microsoft.ServiceBus.Messaging.IteratorAsyncResult 1.StepCallback(IAsyncResult result)Exception rethrown at[3]: at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory 1.StepCallback(IAsyncResult result)Exception rethrown at[3]: at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.Channels.ReconnectBindingElement.ReconnectChannelFactory （IAsyncResult）（IAsyncResult） .Sbmp.SbmpMessageReceiver.EndReceiveCommand（IAsyncResult结果，IEnumerable 1& messages) --- End of inner exception stack trace --- at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.MessageReceiver.RetryReceiveAsyncResult.TryReceiveEnd(IAsyncResult r, IEnumerable System.Threading.Tasks.TaskFactory上Microsoft.ServiceBus.Messaging.MessageReceiver.EndReceive（IAsyncResult结果）处的1& messages) --- End of inner exception stack trace --- at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.Messaging.MessageReceiver.RetryReceiveAsyncResult.TryReceiveEnd(IAsyncResult r, IEnumerable 1＆消息） 1.FromAsyncCoreLogic(IAsyncResult iar, Func 2 endFunction，Action 1 endAction, Task 1承诺，布尔值requireSynchronization）---从上一个引发异常的位置开始的堆栈结束跟踪---位于System.Runtime.CompilerServices.TaskAwaiter.ThrowForN Microsoft.ServiceBus.Messaging.SubscriptionClient.ReceiveAsync（）上的onSuccess（任务任务），位于System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification（任务任务）

Answer 1

我们将很快更新消息传递异常文档。 该信息将存在：

1. 您可能有一个阅读器无法完成消息，并且当锁过期时，消息将返回到队列/主题。 如果阅读器遇到阻止其调用BrokeredMessage.Complete的异常，则可能发生这种情况。 阅读一条消息十次后，默认情况下它将移至“死信队列”。 此行为由QueueDescription.MaxDeliveryCount属性控制，默认值为10。当邮件堆积在死信中时，它们会占用队列中的空间。 要解决此问题，请像从其他队列中读取并完成死信队列中的消息一样。 QueueClient包含格式化死信路径的方法：QueueClient.FormatDeadLetterPath。

2. 另一种可能性是，阅读器已停止从队列或订阅中接收消息。 识别此问题的方法是查看QueueDescription.MessageCountDetails属性，该属性显示消息的完整分类。 如果ActiveMessageCount很高或正在增长，则读取消息的速度不会像写入消息那样快。