Re: Memory leak with log4j 2.13

--Apple-Mail=_E01E459A-1233-4350-8CCF-915B5D4DCA47
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Attachments generally do not make it to the mailing lists. There is no =
leak report attached to the email.

I think you are going to have to explain a little more as to what your =
application was doing that would cause so many Console Appenders.  While =
there is a Default Configuration there is no such thing as a Default =
Console Appender. If you are passing custom patterns to the Console =
Appender then, by definition, you can=E2=80=99t possibly be using the =
Default Configuration.=20

There should never be a reason for there to be more than one Console =
Appender in a Configuration. If you need multiple patterns Log4j =
provides a PatternSelector that you can configure on your Appender to do =
that. Note that these are not dynamically created - you use one of a few =
patterns based on data in the Log Event.   Because of this Log4j has no =
need to protect itself from the problem you describe because it is, =
plain and simple, user error.

It sounds like you have created custom code for Log4j 2. When migrating =
from Log4j 1 to Log4j 2 many teams seem to want to take the approach of =
=E2=80=9CWe have customization X, what do I have to do to make that =
customization to Log4j 2=E2=80=9D. That is always the wrong approach.

The steps for migrations should be:
1. What are our requirements for logging?  What destinations do we need =
to log to and under what circumstances?
2. What facilities does Log4j 2 provide out of the box to meet those =
requirements? =20
3. We aren=E2=80=99t sure which approach is the best to meet requirement =
n - we should seek advice on a Log4j mailing list or StackOverflow.
4. Based on those recommendations, implement what is left.


Ralph


> On Feb 26, 2020, at 5:25 AM, Srijith Kochunni =
<[email protected]> wrote:
>=20
> Hi All,
> =20
>              We recently upgraded our application to log4j 2.13 from =
log4j 1.2.15. Since the upgrade, we=E2=80=99ve 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.
> =20
>           I=E2=80=99ve 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 =
<https://issues.apache.org/jira/browse/LOG4J2-1176> in the code, but the =
problem description did not match.
> =20
> =20
> Thanks,
> Srijith.


--Apple-Mail=_E01E459A-1233-4350-8CCF-915B5D4DCA47--