I have an idea for a set of blog posts that might get me out of the apparent writer's block I have been suffering lately. As developers, we love to debate the "right" way to do something, so I thought I would throw out a few scenarios to see how others perceive the "right" way to solve a problem.
You have a Windows Service application (an application that is controlled through the SCM) written in managed code that performs a lot of work on a continual basis with peak processing times occurring in the middle of the afternoon. The type of work the service performs is the least significant bit for the problem. The service application will emit messages on a continual basis to monitor the application's status (ie., see some evidence of work being performed, current health, overall progress to date, etc).
Your task is to write a Console application that can consume the messages from the service application and display the messages in the console window (for example, maybe it is a simple Console.WriteLine). Neither the production nor the consumption of this diagnostic information can impede performance on the service application itself (or have very limited effects on the service application's primary task of continually processing data ).
For an idea of what this should look like, think about how "tail -f" works when monitoring log files. You open a console window, point it to a file, and then watch as new data is written to the file. How would you write a similar application that monitors these diagnostic messages without impeding the performance of the application itself?
Let's see how you would tackle this, and if you think others are doing it the right way or the wrong way.