Hello,
We use Log4J2 as our logging library both in a Web environment (under Tomcat),
and in command-line utilities. I have noticed recently that our command-line
utilities seem to hang when done: the normal JVM's exit is blocked.
I am on JDK 15 with log4j-web-2.14.1.jar, log4j-core-2.14.1.jar and
log4j-api-2.14.1.jar in the classpath.
My configuration is:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="info">
<Properties>
<Property
name="log-path">C:\Projects\TomcatDevServer\logs\</Property>
<Property name="now">${date:yyyy-MM-dd}</Property>
</Properties>
<Appenders>
<RollingFile name="FILES" fileName="${log-path}/capsico.log"
filePattern="${log-path}/capsico.${now}.%i.log.gz">
<PatternLayout>
<pattern>%d{MMdd.HHmmss.SSS}#%-3t %level{length=1} %15.15c{1}|
%m %ex{50}%n</pattern>
</PatternLayout>
<Policies>
<SizeBasedTriggeringPolicy size="100 MB" />
</Policies>
<DefaultRolloverStrategy max="99999" compressionLevel="6"/>
</RollingFile>
<Async name="ASYNC">
<AppenderRef ref="FILES" />
</Async>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout>
<pattern>%d{MMdd.HHmmss.SSS}#%-3t %level{length=1} %15.15c{1}|
%m %ex{50}%n</pattern>
</PatternLayout>
</Console>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="Console" />
<!--
<AppenderRef ref="ASYNC" />
<AppenderRef ref="Console" />
-->
</Root>
</Loggers>
</Configuration>
We switch between console when developing to async in production, thus the two
options.
My test program is super simple:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class Test
{
protected static final Logger LOG =
LogManager.getLogger(Test.class.getName());
public static void main(String[] args)
{
LOG.debug("Hello");
}
}
This program hangs and doesn't exit. If I replace the Log4J2 JARs with v12.1,
all works as expected. I checked JDK 8 and JDK 11 with the same behavior.
If I remove the <Async> element, it works, pointing to that capability causing
issues. My guess is that a thread is not getting closed and hangs the JVM's
normal exist.
I did not see a reference to some API changes from v12 to v14 that would
explain this, or maybe I missed something? Or maybe it's a bug?
Thank you,
Laurent Hasson