Журнал ошибок WCF

Question

Я работаю над проектом, использующим привязки NetTcp для общения с некоторыми службами WCF. При первом запуске мы взяли пример плохой практики из другого приложения, которое выполняло вызовы WCF, используя следующее:

EntityObject sample = new ServiceProxy().GetEntity();

Это прекрасно работало, пока мы не осознали, что WCF удерживает соединения, даже если страница aspx была отправлена ​​клиенту (что, как я наивно полагал, очистит все соединения). В то время как соединения удерживались, что приводило к замедлению работы, ELMAH регистрировал все ошибки и отправлял нам полные трассировки стека. Чтобы решить проблемы с производительностью, мы изменили это на:

using (ServiceProxy proxy = new ServiceProxy())
{
     sample = proxy.GetEntity();
}

Это сделало производительность рок сравнительно. Недостатком этого метода является то, что всякий раз, когда на прокси-сервере поступает ошибка, единственное, что может поймать ELMAH, - это сбой канала. Затем нам нужно пролистать журналы (настроенные в WCF с использованием sharedListeners), чтобы выяснить, что произошло, и если это ошибка сериализации, шансы на то, что она обнаружится, станут намного ниже, несмотря на то, что слушатели настраиваются как на клиенте, так и на сервере. Я исследовал интерфейс IErrorHandler и собираюсь добавить поддержку этого в наши сервисы, но мне было интересно, есть ли другие способы получить подробные ошибки из WCF вместо того, чтобы просто сказать, что он неисправен без реальной информации о том, почему он нарушенными. Это было бы особенно полезно, если бы он умер при сериализации объекта, который мог бы сказать нам, ПОЧЕМУ он не мог сериализоваться.

Answer 1

Что ж, вы можете сказать серверу WCF отправлять обратно больше информации, чем просто «что-то плохое произошло», используя поведение serviceDebug.

<system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ExceptionDetails">
          <serviceDebug includeExceptionDetailInFaults="True" />
        </behavior>
      </serviceBehaviors>
    </behaviors>

Это нормально, если это среда разработки / тестирования или собственное приложение. Но на самом деле, ошибка службы должна быть обнаружена (и зарегистрирована) на стороне сервера - вы находитесь на правильном пути с интерфейсом IErrorHandler.

Клиент должен обрабатывать исключения на стороне клиента, такие как TimeoutException и CommunicationException, чтобы иметь дело с исключениями безопасности или выходящими из строя сетями и тому подобным. Просто стандартная обработка исключений .NET, на самом деле.

Кроме того, using() является хорошей идеей в целом - но не обязательно здесь, поскольку вы можете встретить исключение, когда ServiceProxy удаляется (в конце блока using() {}), и это выигрывает ' быть пойманным в этом случае. Вам может просто понадобиться использовать блок try {...} catch {...} finally {...} для прокси-серверов службы.

Марк

Answer 2

Я думаю, что если вы явно вызовете Close () для прокси-сервера и включите его в try-catch, вы получите то, что хотите.

Смотрите особенно этот образец:

http://msdn.microsoft.com/en-us/library/aa355056.aspx