We have an application that runs in multiple threads and uses Log4Net as logging framework. We encountered a scenario where some log events weren't logged. As mentioned in the docs, the FileAppender and the other Appenders are "not safe for multithreaded operations".
I searched the web for solutions or Appenders, but couldn't find any.
Do you know a multithread safe Log4Net Appender that uses a ring buffer or a queue to provide multithread support? Or should we use a different multithread safe logging framework at all?
Thanks in advance!
8
votes
Duplicate of stackoverflow.com/questions/1294668 - basically, log4net will use the appender appropriately for you.
– Jon Skeet
Thanks for the answer. I wrote some unit tests that confirm the Log4Net multithread safety (see the answer below).
– Rene Schulte
4 Answers
16
votes
I wrote some Unit tests to reproduce the problem: A test creates 50 threads and each thread logs 500 messages. Afterwards the written lines were counted and as a result I got 25,000 (50 x 500) lines in different order. I tested it on a dual core and on a eight core machine.
I tested a static Logger:
private static ILog StaticLog = log4net.LogManager.GetLogger(RepositoryName, "Static logger");
and with a Logger for each instance of the test class / thread:
ILog instanceLog = LogManager.GetLogger(RepositoryName, "Instance logger: " + ThreadId.ToString());
And all tests were green.
So Log4Net works fine and handles multithreading scenarios well. The Appender docs should be updated and state that multithreaded operations are supported if the Logger API is used in the right way.
I guess the problem with missing log entries that we encountered on a customer's machine is caused by other issues. Maybe the underlying VM or hardware is broken.
Thanks for your help!
8
votes
I've never used FileAppender and cannot say if it is thread safe but I have never had any problems with RollingFileAppender. The docs state that members of the type are not thread safe, but this should be OK unless you try to directly write to the appender. You do not need to add your own locking code around calls like:
log.Info("message");
0
votes
That the tests are green does not mean that the lines were actually written to the file, but that there was no exception. Or did you include check that reads the file for that in your test as well? I encountered the same problem after I switched on web gardens in IIS. At that point only one thread was writing lines to the file.
0
votes
The Log4Net is thread-safe, but the appenders used can be a problem. The file appenders do "block" when called. This means that in your application, every log sent to Log4Net has to complete every appenders before returning to your application.
It is thread-safe, many threads can use Log4Net to log messages, but where Log4Net is called the application waits for the appenders to complete. The execution time of logging is added to your application time.
This is easily proved. See: https://www.codeproject.com/Tips/1219696/Log-Net-Singleton-Wrapper-for-Concurrent-Logging
What I have done is to "wrap" the Log4Net functions in a static singleton that is thread-safe and then put each log message into queue running in a concurrent thread. This make all the logging concurrent to the application but the application execution does not wait for the appenders to complete.
