Shutting down log4net repositories

I’ve been learning and evaluating the Gibraltar ‘Runtime intelligence’ & logging application recently. If you’re already using log4net, there’s a very low impact route to adopting its many benefits by using their simple Gibraltar Appender.

In knocking up a quick sample application to test, I had setup and configured my Log4Net logger:

public class Program
{
  private static readonly ILog Log = 
    LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);
  static int Main(string[] args)
  {
    if (!LogManager.GetRepository().Configured)
    {
      XmlConfigurator.Configure();
    }

The simple application went on to output some simple log lines to test using the Gibraltar appender. All was fine, except this simple console application appeared to hang on exit. I quit the running application and Gibraltar dutifully announced that my session had Crashed.

A bit of headscratching later made me realise that I needed to be a better Log4Net citizen in my sample application. I had omitted the line:

Log.Logger.Repository.Shutdown();

Now my code properly stopped its logging activities before the program exited and Gibraltar was able to report successfully. The Log4Net RollingFileAppender or ConsoleAppenders don’t complain like this on program exit if the repository isn’t shutdown first but it does makes sense to tidy up after yourself rather than relying on the garbage collector.

I’ll write more about my positive experiences of Gibraltar in another post, but just wanted to share this in case any early adopters faced the same ‘facepalm’.

Log4View

I just wanted to personally recommend a log view utility I’ve had the luck of finding recently, actually thanks to Ian again. Around October time, Ian contacted the logging.apache.org group asking :

“Does anyone know of an application that is capable of loading a log file that has been written to using the RollingFileAppender?”

He was answered by Ulrich Proeller, author of Log4View, saying that at the time his application didn’t support that but would process XML Formatted log files.

We’re currently using a ConversionPattern with a Rolling File Appender in Log4Net to custom-format the output of the logs. I did try swapping to the XML format briefly on my development machine, but the output logs really are only machine readable after that.

I recently got in touch with Ulrich as I spotted he’d added Pattern support to Log4View along with XML for file based logs. (For those who prefer network logging, there’s also excellent support for UDP and TCP appenders as well.)

Today, he’s sent me a preview beta copy of Log4View with the pattern changes made and I’m pleased to report it is performing very well. He informs me there’s a new version on the cards very soon which will include the changes he sent me today, alongside some other improvements which sound exciting.

For someone who has spent countless hours trawling through the vast amount of logs that our services can produce while we’re testing them, Log4View offers a very slick, well thought out way of exploring live or archive logs. Being able to specify the Log Level you want for each Logger it finds in the log files, supported by smart Filtering rules really allow you to find what you need quickly.

My thanks go to Ulrich for continuing to actively support his application and for the quick turn-around he’s done after I made suggestions.
If you use Log4Net, you should seriously consider both trialling and supporting Ulrich for his efforts in producing a very useful view on your logged data.