Log4j vs Logback: concurrent writing to same log?

Question

I have several web applications running on the same tomcat.

I have two questions:

1- By searching, I understood that when multiple applications are present, logging into the same file might make some problems. Is that the case for multiple applications running on the same web server? Is that also correct when default stdout output is used?

2- In Logback library there is a prudent mode:

In prudent mode, FileAppender will safely write to the specified file, even in the presence of other FileAppender instances running in different JVMs, potentially running on different hosts. The default value for prudent mode is false.

I want to know if using Logback is only favorable on multiple JVMs or it is also advantageous for multiple we applications running on the same web server? If not, is it identical to log4j in this aspect?

Thanks

Answer 1

In both log4j and logback if multiple FileAppender instances write to the same log file, there is a high risk for the said log file becoming corrupt. Whether the FileAppender instances run on the same JVM or different JVMs is irrelevant, i.e. the risk of corruption is the same.

As mentioned in the docs, in prudent mode logback's FileAppender will avoid corruption, even in the presence of other FileAppender instances running in the same or different JVMs, potentially running on different hosts. By default, prudent mode is disabled.

The console cannot be corrupted so the question is moot.

Answer 2

There's one thing which must be clarified: There will be problems when different instances of Log4j are writing to the same file concurrently, whether running in the same JVM or not.

When using servers (and different classloaders) it is possible to have a single server-wide instance or multiple instances of Log4j, depending on deployment and configuration.

1. See above. Stdout can suffer the same mixed output problem, but not when rotating files.
2. Logback's prudent mode would address concurrent writing by different instances (same JVM or not). If your configuration uses a server-wide Log4j instance there's no advantage for this aspect.

Answer 3

Using Filelocks is never actually efficient/secure, so while logging to the same file from different appenders/JVM's works, it is not recommended. See the configuration which I took directly from logback-appenders-faq.

<configuration>
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <!-- Support multiple-JVM writing to the same log file -->
    <prudent>true</prudent>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern>
      <maxHistory>30</maxHistory> 
    </rollingPolicy>

    <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
  </appender> 

  <root level="DEBUG">
    <appender-ref ref="FILE" />
  </root>
</configuration>

Your other options for multiple JVMs writing to some unified source are SocketAppenders and the JDBCAppender.

The JDBCAppender will be completely replaced in the future though and is not recommended either. See logbacks mailinglist.

SocketAppenders might be a little raw, as you probably weren't planing on writing much code for logback.

There is one more option. You could use something like clusterlog, which has been build to solve exactly the kind of problem you have.