Hi All,
We recently upgraded our application to log4j 2.13 from log4j
1.2.15. Since the upgrade, we've noticed in one of our test setups that the
application is running out of heap space. Upon inspecting the heap dump, we
found that there are almost a 100 thousand entries in the HashMap owned by
AbstractManager instance. Upon further investigation of the heap dump, we were
able to determine that this is because a large number of Default Console
Appender instances are being created. We have reason to suspect that one of our
modules might be passing multiple different patterns during logging and the
Pattern Layout is invoking the init of DefaultConfiguration due to the pattern
being different every time. We are looking at determining the faulty modules
and fixing them, but is there not a way to ensure these Console Appender
instances are garbage collected later or turn off the creation of these Default
Console Appender instances ? I did not see any such flags to stop this in the
code but still wondering if we really need to have so many instances loaded in
memory.
I've attached the leak report here. Not attaching the heap dump,
because I have some proprietary information on it. Saw a reference to
https://issues.apache.org/jira/browse/LOG4J2-1176 in the code, but the problem
description did not match.
Thanks,
Srijith.
