Use SemanticLogging-svc.exe with Original EntLib Logging?

Topics: Logging Application Block, Semantic Logging Application Block
Mar 14, 2014 at 9:23 PM
We looked at Semantic logging but we're pretty heavily invested in the original (Microsoft.Practices.EnterpriseLibrary.Logging) logging. However, we are interested in ways to mitigate logging performance overhead. Is there a way to use SemanticLogging-svc.exe with the original Enterprise Library logging?

I previously experimented with the Distributor Service in Enterprise Library 5 but it wasn't able to keep up with our logging volume and the MSMQ queue exceeded its capacity.

The new "asynchronous" trace listener attribute in Enterprise Library 6 is promising but messages still in the buffer at application shutdown are lost. For abnormal shutdowns those lost message could contain valuable diagnostic information.
Mar 15, 2014 at 6:09 AM
Also, for asynchronous logging the buffer can overflow and messages can be dropped.

There is no out of the box way to send Logging Application Block LogEntry's to the Semantic Logging Block out-of-process service. However, If you already have an application that is using LAB you could create an EventSource that can Log the LogEntry data and then create a custom trace listener that writes to that EventSource. If you are using Extended Properties then that might be a bit That approach would minimize any changes to an existing application since you would just need to change some configuration. The negative would be that the LAB overhead would still be present which might be a factor if you are having large volumes. But if you skipped LAB to minimize overhead that wouldn't really be using the original LAB.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Marked as answer by DavidHerbst on 3/18/2014 at 7:51 AM
Mar 17, 2014 at 4:31 PM
Thanks Randy

We're not too concerned about original LAB overall overhead, its only when logging to the database that logging overhead has been a problem for us. In contrast, flat file logging via LAB hasn't been a problem.

For asynchronous logging, the buffer size is configurable so we could increase it in order to lessen the chances of losing messages due to overflow. I assume the tradeoff is that increasing the buffer size would increase memory consumption?

If we have multiple listeners that are configured to be asynchronous, would they share the same buffer or is there a separate buffer per asynchronous listener?
Mar 18, 2014 at 2:20 AM
If you increase the buffer size you may increase memory usage (assuming the buffer actually fills). Also, if the application crashes more messages may potentially be lost.

Each asynchronous listener gets it's own buffer (implemented as a BlockingCollection).

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Marked as answer by DavidHerbst on 3/18/2014 at 7:51 AM