Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.11.0
-
None
Description
Hi all!
We are using log4j2 as the logging framework for our applications.
This is done by using the log4j implementation provided for slf4j.
The problem we are seeing is that after many application redeploys, many LoggerContexts are still referenced, even after stopping them.
I've taken many heap dumps of our standalone server and found that many of these references are kept by a WeakHashMap<> instantiated in the Log4jLoggerFactory. ('registry' attribute of org.apache.logging.log4j.spi.AbstractLoggerAdapter)
What happens is that, even when the Map is a WeakHashMap (Where the keys should be weakly referenced), it will never be cleared because it's values keep references to those same keys.
If you check the heap dumps that i've provided, you can see that most of the LoggerContexts (org.mule.runtime.module.launcher.log4j2.MuleLoggerContext) states are: STOPPED and even it's loggers configurations are updated to NullConfiguration, but the references are kept.
On the other hand, i could remove the references to their contexts for the loggers ('context' attribute of org.apache.logging.log4j.core.Logger) when those contexts are stopped but the field is final and private, which makes it impossible to change for an child class.
For the heapdumps, i took them as follows:
- deployed application
- dumped patched_before.hprof
- redeployed app 10 times
- dumped patched_after.hprof
- waited an hour
- dumped patched_after_waited.hprof
You can see that in patched_before.hprof there are only 4 LoggerContext instances while in patched_after.hprof and patched_after_waited.hprof there are around 16, most of them referenced by a logger that is linked to a value in the WeakHashMap mentioned above.
I think that you should, either provide a way to remove entries from that 'registry', or check for circular dependencies somehow so that they are removed by the GC.
Thanks!