Logback reliability - logback

Question

Log4j is not reliable as per the following faq:
http://logging.apache.org/log4j/1.2/faq.html#a1.2
"No. log4j is not reliable. It is a best-effort fail-stop logging system."
Is Logback more reliable? Is it possible that when 1000 log messages (for example) are written using logback in a very short span of time, it might silently miss a few messages.
Thanks,
Sunil

Answer 1

I think that Logback is also a best-effort fail-stop logging system. Run this snippet:
for (int i = 0; i < 8; i++) {
System.out.println("log " + i);
logger.info("log {}", i);
Thread.sleep(2000);
}
with a FileAppender:
<appender name="file" class="ch.qos.logback.core.FileAppender">
<file>/mnt/logtest/testlog.log</file>
<append>false</append>
<encoder>
<pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern>
</encoder>
</appender>
on a disk which has no free space. Then it runs without any errors. A few seconds later I've deleted some files from the disk.
The contents of the testlog.log file was that:
2011-10-07 08:19:01,687 [main] INFO logbacktest.LoopLog - log 5
2011-10-07 08:19:03,688 [main] INFO logbacktest.LoopLog - log 6
2011-10-07 08:19:05,688 [main] INFO logbacktest.LoopLog - log 7
There is no log 0 - log 4 lines in the file. I wouldn't think that other appenders more reliable.
In normal operating conditions (e.g. system has enough disk space) I've never seen that Logback lost a message. In that meaning I think it's reliable. But if you want to do audit logging I think you should use something else, not a best-effort fail-stop logging system. (If an attacker found a way to disable the logging by filling the disk space he can do everything on the user interface without any audit log and notice that the disk was full.)

Answer 2

The short answer is No, logback is not reliable. Even It is very very unreliable if you benchmark it with other logging frameworks such as log4j, log4j2, JUL and etc.
In fact, Logback has the highest performance but drops some of its log events in order to do so. This is due to the behavior of Logback’s AsyncAppender, which drops events below the WARNING level if the queue becomes 80% full.
There’s often a trade-off between fast and reliable logging. Logback, in particular, maximized performance by dropping a larger number of events, especially when we used an asynchronous appender. Log4j 1.2.17 and 2.3 tended to be more conservative but couldn’t provide nearly the same performance gains.