Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-929

Some appenders prevent quitting of application if loggerContext.stop() isn't called.

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.13
    • Fix Version/s: 1.1.3
    • Component/s: logback-core
    • Labels:
      None

      Description

      Using SocketAppender (probably others) prevents exit of a simple command line application if loggerContext.stop() isn't called explicitly.

      Calling loggerContext.reset() without reinitializing it afterwards is not sufficient.

      This is caused by a dangling thread pool:

      "pool-1-thread-1" prio=5 tid=0x00007fed0a09a000 nid=0x6403 waiting on condition [0x0000000117aac000]
      java.lang.Thread.State: WAITING (parking)
      at sun.misc.Unsafe.park(Native Method)

      • parking to wait for <0x00000007aeb00528> (a java.util.concurrent.SynchronousQueue$TransferStack)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
        at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
        at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
        at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:925)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:744)

      The reason for this is that `stopExecutorService()` is not called in `reset()` of https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/ContextBase.java

      I wouldn't necessarily call this a bug but it's at least a bit surprising that an already removed appender is still having an influence on the behavior of the logging system.

      This could be circumvented by using a http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadFactory.html other than `Executors.defaultThreadFactory()` for the threads of the `ExecutorService` created in https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/util/ExecutorServiceUtil.java

      That factory could create daemon threads instead of the current non-daemon ones and could also specify a better name than "pool-1-thread-1".

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tony19 Tony Trinh
                Reporter:
                jhuxhorn Joern Huxhorn
              • Votes:
                3 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: