Robust logging solution to file on disk from multiple threads on serverside code

I have implemented a socket listener that runs on my Linux Ubuntu server accepting connections and then starting up a new thread to listen on those connections (classic socket listener approach). The socket listener is persistant and the way it is restarted is by restarting the server.

I have implemented a logging feature in the code so that information such as the data received, any events that have occurred etc are logged to a file. All threads log to this same file and the file is named by the day it's on. So I end up with log files such as 2012-May-01.txt, 2012-May-02.txt etc etc.

In order to provide this logging, I implemented a couple of classes to handle the logging.

• EventLog - Just a wrapper to hide away my actual logger and what is used by the various threads etc for logging

• Logstream - The class that does the logging to file

I'm a bit concerned about this class and ensuring I capture all log events. As it can be called by multiple threads I do not want to lose any information.

I'm pretty sure logging is such a common issue so I'm hoping someone can point out the issues in this code and provide a much more robust solution. I am potentially going to look into other existing logging solutions as suggested by sudmong, but for now this is the easiest for me to get my head around (assuming it's a valid solution).

Important: I want to keep the facility to log items in a file naming convention that fits the day the item was logged. I don't want one log file that spans multiple days etc

EDIT: Following from X-Zero's comments I've changed my logging mechanism to use a BlockingQueue approach. Does this seem like a scalable solution if I was to look at logging perhaps up to 100 lines per second? The main issue I can see is perhaps the opening and closing of my log file for every log write and whether I should catch the FileWriter handle and only re-create on each new day?

```
// Class interface through which all logging occurs
publi

Here are some ideas:

• For better granularity of logs, if you're looking at high performance, write on a minutely, or hourly basis. Use the idea of writing to logs as jobs, each dispatched to a thread. This makes searchability of log files inherently parallelizable.

• Use a shutdown hook to flush on shutdown.

• Keep an option to convert your log class into out-of-proc - like a TCP Daemon or web server + client library.... That will definitely help all the applications you write, including those which crash sporadically.

StackExchange Code Review Q#12336, answer score: 4