logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Karlstrom <karlst...@corporater.com>
Subject Log4j 1.2.x deadlock bug or faulty usage?
Date Mon, 20 Oct 2008 13:19:18 GMT
We are experiencing deadlocks on our server.

We have tested with log4j version 1.2.8 up to and including 1.2.15

We have identified that cause to be a log statement inside a 
synchronized block,
which is called from different threads.

We have attached to very simplified classes, to reproduce the deadlock. 
Our framework is a lot more complex, where log4j can be called 
indirectly with reflection, not neccessarily by us, but from third party 
libraries etc.

The deadlock can be reproduced always.

Is our usage (or library usage) of log4j faulty, or is it a bug?

import org.apache.log4j.Logger;

public class FindDeadLock {

   public static void main(String[] args) {
       new Thread(new Runnable() {
           public void run() {
               Logger.getLogger(getClass()).info(new FindDeadLock());
     public String toString() {
       /* now we are inside log4j, try to create a DeadLockingObject */
       return "Created DeadlockObject, returning string";

import org.apache.log4j.Logger;

public final class DeadLockingObject {
   private static final Logger LOG = 
   private static DeadLockingObject singleton = new DeadLockingObject();

   private DeadLockingObject() {}

   public synchronized static DeadLockingObject getInstance() {
       try {
           //to make the deadlock occur
       } catch (InterruptedException e) {

       LOG.info("Returning nice singleton");
       return singleton;


Here is our log4j configuration:

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=INFO, A1

# A1 is set to be a ConsoleAppender.

# A1 uses PatternLayout.
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

best regards frank karlstøm,
senior developer.

View raw message