Pluggable log systems

In the past I’ve mentioned my lack of enthusiasm for the normal ‘debug trace’ files that some systems seem to include… I pretty much consider them a design smell… But, some of my clients seem to like them and over the years I’ve been asked to provide high performance logging systems so that they can spew random messages to files and still run at a reasonable speed. I’ve written and adjusted an asynchronous file writing log file class a couple of times now and it finally ripened to the point where it was time to harvest it.

I finally decided that my standard response of “don’t use the debug trace facility in The Server Framework libraries if you want any kind of performance” was a bit of a lame excuse. Even though The Server Framework itself doesn’t use it and it’s only used in the examples… Still, people take examples as, well, examples, and so I decided to make it easier to use a decent log with decent performance characteristics… The result was a pluggable log system, although I’m a firm believer of “parameterize from above” and have an “issue” with singletons that allow global access to the object, I’m not so unreasonable to expect you to pass a log object into every object that you want to log from…

So, all of the example program’s calls to Output() are now routed through to a CDebugTrace singleton that provides access to a pluggable instance of something that implements ILogMessages. The default is a slightly cleaned up version of the original slow and nasty logging code, but you can easily replace that now with a file log that runs using overlapped I/O and async writes and that motors along at a much faster pace; it’s even lock free on x64 thanks to the InterlockedXXX64() stuff…

Next on the list, write a syslog compatible plug in and, if that doesn’t quite do it for me, write my own log protocol and accompanying server…