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,
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:
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
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
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
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
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
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
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
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 (
10 matches
Mail list logo