Hi Srijith, Thanks for reaching out. Could you file a jira issue to track all of this information? If you could attach or link a minimal reproducer that would be tremendously helpful.
Thanks, -ck On Wed, Feb 26, 2020, at 07:25, Srijith Kochunni wrote: > 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.
