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