Ведение журнала ошибок WCF на границе службы

Question

Я пытаюсь реализовать IErrorHandler в моей службе WCF, чтобы регистрировать каждое исключение, которое попадает в границу службы, прежде чем она будет передана клиенту. Я уже использую IErrorHandlers для перевода исключений в типизированные исключения FaultExceptions, что было очень полезно. Согласно MSDN для IErrorHandler.HandleError (), он также предназначен для ведения журнала на границе.

Проблема в том, что функция HandleError не гарантированно вызывается в потоке операций, поэтому я не могу понять, как получить информацию о том, какая операция вызвала исключение. Я могу получить TargetSite из самого исключения, но это дает мне внутренний метод вместо операции. Я мог бы также проанализировать строку StackTrace, чтобы выяснить, куда она была брошена, но это кажется немного хрупким и фальшивым. Есть ли какой-либо согласованный, поддерживаемый способ получения какой-либо информации о состоянии (сообщения, описание операции и т. Д.) В функции HandleError? Или какие-либо другие способы автоматически регистрировать исключения для вызовов службы?

Я ищу решение, которое можно внедрить в производство, используя мою существующую среду ведения журналов, поэтому SvcTraceViewer не сделает это за меня.

Спасибо.

Answer 1

В итоге я поместил запись в IErrorHandler.ProvideFault () вместо IErrorHandler.HandlerError (). Вызов ProvideFault выполняется в потоке операций, поэтому я могу использовать OperationContext.Current, чтобы получить некоторую информацию для регистрации.

Answer 2

Вы можете сохранить любую контекстную информацию, необходимую для входа в словарь данных исключения, в методе ProvideFault, который вызывается в потоке операций ... а затем ссылаться на него в методе HandleError для целей ведения журнала.

Answer 3

Я использую IErrorHanlder так же, как вы описываете, но не для ведения журнала. Вместо классов обслуживания (WCF или нет) я использую перехватчик, как описано здесь . Я считаю, что эта техника будет захватывать интересующую вас информацию.

Answer 4

А как насчет создания экземпляра и сохранения сообщения запроса на этом экземпляре?

Answer 5

Операции ProvideFault () вызываются в потоке входящих вызовов, и клиент по-прежнему блокируется в ожидании ответа. Я не думаю, что это хорошая идея, чтобы добавить длительный процесс (например, ведение журнала) внутри этого метода. Вот почему они выставили еще одну операцию HandleError, которая вызывается в отдельном рабочем потоке.

Но я понимаю вашу ситуацию. Пожалуйста, поделитесь, если вы нашли решение, отличное от входа внутри ProvideFault.

Answer 6

Использовали ли вы Service Trace Viewer ?