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

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 2

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.

Answer 3

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 4

1. Yes. In general, your principle should be that you write a different log file for each application (web or not). The alternative, is that you leave it up to the server to decide on the file to write to. JBoss has ways to genericly log out, which will go to the same file. However, I still prefer to have a separate log for each application.
2. As far as I know, both log4j and Logback aim to be minimal in the overhead they can cause the application, so there's unlikely to be one that's more favourable. If multiple JVMs is essential for you, I believe Logback is better at handling it, but using it outside this is not a bad idea.