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".