Thread-safe прослушиватель трассировки на основе XmlWriterTraceListener

Question

Я хочу заменить XmlTraceListener Microsoft по умолчанию на прослушиватель, который переключает файлы на основе ограничения размера файла или текущей даты. Я хочу сохранить формат файла XmlTraceListener по умолчанию, чтобы я мог открывать файлы с помощью инструмента ServiceTraceViewer.

Я нашел статью http://www.codeproject.com/Articles/30956/A-Rolling-XmlWriterTraceListener, но из комментариев кажется, что у этого слушателя есть некоторые неустойчивости даже после того, как были предложены исправления.

Тогда я нашел собственную реализацию Microsoft по CircularListener http://msdn.microsoft.com/en-us/library/aa395205.aspx

Я хотел расширить его, но заметил, что он имеет

static CircularStream m_stream = null; 

, а затем эта переменная осуществляется доступ без замков. При чтении http://msdn.microsoft.com/en-us/library/ms733025.aspx я обнаружил, что даже сам XmlWriterTraceListener не является потокобезопасным. MSDN говорит:

Поскольку System.Diagnostics.XmlWriterTraceListener не поточно- источник трассировки может блокировать ресурсы исключительно при выводе следов. Когда многие потоки выводят трассировки в источник трассировки, сконфигурированный , чтобы использовать этот прослушиватель, может возникнуть конфликт ресурсов, что приводит к существенной ошибке производительности в . Чтобы решить эту проблему, вы должны: реализовать пользовательский прослушиватель, который является потокобезопасным.

Так по существу это означает, что TraceListener.IsThreadSafe имущество остается в качестве false для XmlWriterTraceListener, так тогда система высшего отслеживании уровня блокировки каждый раз, когда TraceData/TraceEvent называется, я прав?

Будет ли какая-либо польза от добавления блокировки вокруг этого static CircularStream m_stream и возврата true Форма override IsThreadSafe property? Или, может быть, это будет то же самое, что уже сделано в XmlTraceListener?

Что я могу сделать, чтобы сделать CircularTraceListener потокобезопасным и эффективным?

Answer 1

0 думаю, CircularTraceListener в основном недостатки. Как вы заметили, есть staticm_stream. Но, что еще хуже, когда вы строите CircularTraceListener, он проходит по новому потоку к базе (XmlWriterTraceListener). Это означает, что хотя CircularTraceListener знает только об , последний создал поток, базовый класс потенциально использует один из многих потоков. И, конечно же, если CircularTraceListener будет удален, базовый класс будет располагать общий объект m_stream.

Я бы порекомендовал, чтобы вы ничего не основали от CircularTraceListener и начали с нуля.

обновление:

Я имел гораздо лучше удачи с вещами, как log4net и NLog для таких вещей, как циклическое ведение журнала.