开发者

enterprise library 3.1 - if one listener is failed then subsequent listener will be never executed

开发者 https://www.devze.com 2023-04-12 07:51 出处:网络
I am using Msmqdistributor service of Enterprise Library 3.1 to distribute logs from various application.I have defined multiple listeners in categorySources/specialSources, but if one listener is fai

I am using Msmqdistributor service of Enterprise Library 3.1 to distribute logs from various application.I have defined multiple listeners in categorySources/specialSources, but if one listener is failed than subsequent listeners will be never executed.

Following is my config code.

<specialSources>
      <allEvents开发者_JAVA技巧 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>

If I am specifying wrong connection string for Database Listener A then it will be failed to insert logs in database. But it also stops the jobs of next Custom Trace Listener A and Custom Trace Listener B.So here Custom Trace Listener A and Custom Trace Listener B will be never executed if Database Listener A is failed.

Anybody can help please ?

Thanks Mitesh Patel


This behavior seems to be "by design". See the answer for Microsoft Enterprise Library 4.1 Logging Fails on Windows XP SP3.

Of course, this doesn't really help you. One workaround would be to attach one listener to a category. So for your 3 listeners you could add 3 categories. This will work but is not particularly elegant.

Since you indicate that you are using 2 custom trace listeners another approach to mitigate the issue would be to code the custom trace listeners to swallow any exceptions (not usually a good idea, though). You could also order your trace listeners from least likely to fail to most likely to fail. E.g. Database > Event Log > Flat File. In your scenario place the custom trace listeners before the database trace listener.

It is also good practice to add a trace listener to the errors category. Not sure if you have that in your app or not (but the posted config doesn't).

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号