Реле служебной шины Azure Иногда FaultException

Question

Мы не можем определить, почему Azure BasicHttpRelay выбрасывает время от времени FaultException без каких-либо подробностей. Мы включили диагностическую трассировку WCF, но доступная информация трассировки стека остается прежней. Похоже, что клиентский канал WCF не работает в течение короткого времени, а затем вскоре возвращается.

Мы кешируем канал WCF (например,CreateChannel), но мы впервые столкнулись с таким странным поведением. У нас есть другие решения ретрансляции Azure Service Bus, которые прекрасно работают с этим подходом.

Сообщение об ошибке:

Произошла ошибка при обработке запроса.

Трассировки стека:

   в System.ServiceModel.Channels.ServiceChannel.HandleReply(операция ProxyOperationRuntime, ProxyRpc& rpc) в System.ServiceModel.Channels.ServiceChannel.Call(строковое действие, логическое одностороннее выполнение, операция ProxyOperationRuntime, объект [время] аутс, Time [Object]] time, Object[Time OutSense, Object Time] ObjectSSense, TimeSource Object, Time Time Object, Object[Time Out], TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, TimeSource Object, Time Time ObjectStation, TimeSource Object, Time Object, TimeSense, Object Object [], TimeSense, Object[Time] InSense, Object Time [Object] TimeSense, Object[Time] OutSense, Object Time [Object Out] TimeSpace, Object[Time] OutSense в System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (метод IMethodCallMessageCall, операция ProxyOperationRuntime) в System.ServiceModel.Channels.ServiceChannelProxy.Invoke (сообщение IMessage) Исключительная ситуация rethrown.Sec (IMessage reqMsg, IMessage retMsg) в System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, тип Int32) в [нашем методе WCF]...

FaultException - FaultCode Подробности:

Имя: ServerErrorFault
Пространство имен: http://schemas.microsoft.com/netservices/2009/05/servicebus/relay
IsPredefinedFault: false
IsReceiverFault: false
IsSenderFault: false

Мыло сообщение

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header />
  <s:Body>
    <s:Fault>
      <faultcode xmlns:a="http://schemas.microsoft.com/netservices/2009/05/servicebus/relay">a:ServerErrorFault</faultcode>
      <faultstring xml:lang="en-US">There was an error encountered while processing the request.</faultstring>
      <detail>
        <ServerErrorFault xmlns="http://schemas.microsoft.com/netservices/2009/05/servicebus/relay" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" />
      </detail>
    </s:Fault>
  </s:Body>
</s:Envelope>

Посредством отладки мы видим, что сервер правильно отвечает на запросы сообщений (через IDispatchMessageInspector), но клиент не может обработать ответ соответствующим образом (IClientMessageInspector сообщает об ошибке). Последующие запросы ретрансляции будут успешными после того, как клиентский канал, по-видимому, исправится. Эти сбои кажутся прерывистыми и не зависят от нагрузки. Мы никогда не видим этих FaultException ошибки при использовании basicHttpBinding вне лазурной эстафеты.

У кого-нибудь есть предложения? Мы используем Azure SDK 1.8.

Я попытался настроить новое пространство имен Service Bus Relay, используя owner поделились секретом, но все равно видим те же результаты.

Answer 1

После обращения к MS - эта проблема оказалась ошибкой MS с Relay или SDK, особенно при использовании режима подключения Http. На этом этапе единственный обходной путь - убедиться, что у вас открыты соответствующие исходящие порты TCP для обеспечения надежного соединения с ретранслятором Azure.

Разрешить исходящие порты TCP: 9350 - 9354

MS сказал нам, что они все еще работают над устранением первопричины. Надеюсь, этот обходной путь поможет другим. Наш корпоративный брандмауэр заблокировал эти TCP-порты, что привело к принудительному общению через порт 80, который должен вызвать эту проблему. Положительным моментом является то, что открытие этих портов обеспечивает более быструю связь с ретранслятором при запуске слушателей ( AutoDetect не должен каждый раз проверять доступность портов TCP).