Re: Memory leak with log4j 2.13

Ralph Goers <[email protected]> Wed, 26 Feb 2020 08:31:15 -0700
Newsgroups gmane.comp.apache.logging,gmane.comp.jakarta.log4j.user,gmane.comp.apache.sling.devel
Message-ID <[email protected]>
--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
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div =
class=3D"">Attachments generally do not make it to the mailing lists. =
There is no leak report attached to the email.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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. &nbsp;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.&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">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. &nbsp; Because of this Log4j =
has no need to protect itself from the problem you describe because it =
is, plain and simple, user error.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The steps for migrations should be:</div><div class=3D"">1. =
What are our requirements for logging? &nbsp;What destinations do we =
need to log to and under what circumstances?</div><div class=3D"">2. =
What facilities does Log4j 2 provide out of the box to meet those =
requirements? &nbsp;</div><div class=3D"">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.</div><div class=3D"">4. Based =
on those recommendations, implement what is left.</div><div class=3D""><br=
 class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">Ralph</div><br class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Feb 26, 2020, at 5:25 AM, =
Srijith Kochunni &lt;<a href=3D"mailto:[email protected]" =
class=3D"">[email protected]</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"WordSection1" style=3D"page: WordSection1; caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;"><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D"">Hi =
All,<o:p class=3D""></o:p></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 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.<o:p class=3D""></o:p></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><o:p class=3D"">&nbsp;</o:p></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I=E2=80=99=
ve attached the leak report here. Not attaching the heap dump, because I =
have some proprietary information on it. Saw a reference to<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"https://issues.apache.org/jira/browse/LOG4J2-1176" style=3D"color:=
 rgb(5, 99, 193); text-decoration: underline;" =
class=3D"">https://issues.apache.org/jira/browse/LOG4J2-1176</a><span =
class=3D"Apple-converted-space">&nbsp;</span>in the code, but the =
problem description did not match.<o:p class=3D""></o:p></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><o:p class=3D"">&nbsp;</o:p></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><o:p class=3D"">&nbsp;</o:p></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D"">Thanks,<o:p class=3D""></o:p></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" =
class=3D"">Srijith.</div></div></div></blockquote></div><br =
class=3D""></body></html>=

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