In my last post, I talked about a shortcoming of Log4j with a thread leak. I took a look at the Log4j 2 source code to see if it suffers from a similar issue.
The Log4j 2 implementation that checks for changes to the configuration file is handled by FileConfigurationMonitor.java. No threads are created to monitor changes, and from my testing, I saw no thread leaks re-deploying my application to Tomcat.
The new behavior calls FileConfigurationMonitor.java checkConfiguration method during each logging call. If the time since the last check has exceeded your monitorInterval passed into the logging configuration and the file has been modified on the disk, the configuration is reloaded.
The behavior works as expected, but I encountered and initial issue by setting my refresh interval to 1 second...the minimum amount of time one can check for changes to the configuration file is hard-coded at 5 seconds. "But Log4J, what if I have a requirement where I need to apply the change within 1 second????" Five seconds seems like enough time between checks, and I could probably write my own implementation to get rid of the hard-coded limitation and plug it in somehow. But, why choose 5 seconds as the minimum and give no way to change it?
From my brief experience with Log4j 2, I like the APIs, ease of configuration settings, and will look forward to the promise of performance increases (those are always welcome no matter how small in any software). And best of all, no thread leak!