Корпоративная библиотека 3.1 - если один прослушиватель вышел из строя, последующий прослушиватель никогда не будет выполнен

Question

Я использую службу Msmqdistributor Enterprise Library 3.1 для распространения журналов из различных приложений. Я определил несколько прослушивателей в categorySources / specialSources, но если один из прослушивателей окажется неудачным, последующие прослушиватели никогда не будут выполнены.

Ниже приведен мой конфигурационный код.

<specialSources>
      <allEvents switchValue="Warning" name="All Events">
        <listeners>
          <add name="Database Listener A" />          
          <add name="Custom Trace Listener A" />
          <add name="Custom Trace Listener B" />
        </listeners>
      </allEvents>
      <notProcessed switchValue="Warning" name="Unprocessed Category" />        
      <errors switchValue="Warning" name="Logging Errors &amp; Warnings"/>        
</specialSources>

Если я указываю неправильную строку подключения для Database Listener A , то не удастся вставить журналы в базу данных. Но это также останавливает задания следующих настраиваемых прослушивателей трассировки A и настраиваемых прослушивателей трассировки B . Так что здесь настраиваемые прослушиватели трассировки A и настраиваемые прослушиватели трассировки B не будут выполняться, если Database Listener A не удалось.

Кто-нибудь может помочь, пожалуйста?

Спасибо Митеш Патель

Answer 1

Такое поведение, кажется, "по замыслу". См. Ответ для Microsoft Enterprise Library 4.1 Сбой регистрации в Windows XP SP3 .

Конечно, это действительно не поможет вам. Одним из обходных путей было бы присоединение одного слушателя к категории. Таким образом, для ваших 3 слушателей вы можете добавить 3 категории. Это будет работать, но не особенно элегантно.

Поскольку вы указываете, что используете 2 настраиваемых прослушивателей трассировки, другой подход для смягчения этой проблемы заключается в кодировании настраиваемых прослушивателей трассировки для проглатывания любых исключений (хотя обычно это не очень хорошая идея). Вы также можете приказать слушателям трассировки от наименьшей вероятности сбоя к наиболее вероятной ошибке. Например. База данных> Журнал событий> Плоский файл. В вашем сценарии разместите настраиваемые прослушиватели трассировки перед прослушивателем трассировки базы данных.

Рекомендуется также добавить прослушиватель трассировки в категорию ошибок. Не уверен, есть ли это в вашем приложении или нет (но опубликованный конфиг не имеет).