Re: Asynchronous Compression and JVM Shutdown

2017-01-23 Thread Robert Schmidtke
It appears version 2.8 is close to being released, will it be possible to get the RollingFileManager threads out of the thread group and join(); them, like I had tried before? 2.7 uses thread groups as well in its factory, yet I don't see the RollingFileManager threads during shutdown. Anyway,

Re: Asynchronous Compression and JVM Shutdown

2017-01-23 Thread Robert Schmidtke
Hi all, thanks for all the replies and details. I looked into the source and it would seem that for a shutdown timeout of 0, the executor service does not wait for all threads to complete, because it's missing the awaitTermination(); call:

Re: Asynchronous Compression and JVM Shutdown

2017-01-23 Thread Mikael Ståldal
The problem with Log4j 2.7 is that it uses a pool of non-daemon threads for the RollingFileManager tasks. This will needlessly block application shutdown when the application exit by returning from the main method (and not use System.exit()). If you use System.exit(), you will not experience this

Re: Asynchronous Compression and JVM Shutdown

2017-01-22 Thread Remko Popma
More specific 2.7 source links: https://logging.apache.org/log4j/log4j-2.7/log4j-core/xref/org/apache/logging/log4j/core/LoggerContext.html (executors are started around line 508) and

Re: Asynchronous Compression and JVM Shutdown

2017-01-22 Thread Remko Popma
You can browse the 2.7 source here: https://logging.apache.org/log4j/2.x/log4j-core/xref/index.html Remko Sent from my iPhone > On Jan 23, 2017, at 8:04, Apache wrote: > > In 2.7 the threads are owned by an ExecutorService that creates threads using > the name of

Re: Asynchronous Compression and JVM Shutdown

2017-01-22 Thread Apache
In 2.7 the threads are owned by an ExecutorService that creates threads using the name of the LoggerContext. The LoggerContext owns the ExecutorService. Ralph > On Jan 22, 2017, at 3:55 PM, Robert Schmidtke wrote: > > It appears the thread is not currently active. I've

Re: Asynchronous Compression and JVM Shutdown

2017-01-22 Thread Robert Schmidtke
It appears the thread is not currently active. I've added a shutdown hook for testing that lists all threads in the current thread group, similar to how they're created in the Log4jThreadFactory, but the RollingFileManager threads are not there. All I see are a bunch of

Re: Asynchronous Compression and JVM Shutdown

2017-01-22 Thread Robert Schmidtke
Hi Ralph, thanks for your reply. I'm using Log4j2 version 2.7. Which behavior does this version have? Shutdown completes in a reasonable amount of time, yet the compression action thread cannot finish. Is there a version that does wait for the threads? Is there anything I can do to help on this

Re: Asynchronous Compression and JVM Shutdown

2017-01-22 Thread Apache
It is actually interesting that you mention that as I am working on that code right now. This is a bit of code that has been troublesome for us and the behavior depends on which version of Log4j you are using. Log4j used to spawn a thread to do the compression and the thread did not always

Asynchronous Compression and JVM Shutdown

2017-01-22 Thread Robert Schmidtke
Hi everyone, I am currently debugging an issue, and I would like to know how an asynchronous compression action that is currently running in a thread created through the rolling file manager (