Memory leak with log4j 2.13
Srijith Kochunni <[email protected]> Wed, 26 Feb 2020 12:25:40 +0000
| Newsgroups | gmane.comp.apache.logging.log4net.devel,gmane.comp.jakarta.log4j.user,gmane.comp.apache.commons.general |
|---|---|
| Message-ID | <CH2PR18MB3270B7155D3E2949CEEE11C7E9EA0@CH2PR18MB3270.namprd18.prod.outlook.com> |
--_004_CH2PR18MB3270B7155D3E2949CEEE11C7E9EA0CH2PR18MB3270namp_
Content-Type: multipart/alternative;
boundary="_000_CH2PR18MB3270B7155D3E2949CEEE11C7E9EA0CH2PR18MB3270namp_"
--_000_CH2PR18MB3270B7155D3E2949CEEE11C7E9EA0CH2PR18MB3270namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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, w=
e found that there are almost a 100 thousand entries in the HashMap owned b=
y AbstractManager instance. Upon further investigation of the heap dump, we=
were able to determine that this is because a large number of Default Cons=
ole Appender instances are being created. We have reason to suspect that on=
e of our modules might be passing multiple different patterns during loggin=
g and the Pattern Layout is invoking the init of DefaultConfiguration due t=
o 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 Con=
sole Appender instances are garbage collected later or turn off the creatio=
n of these Default Console Appender instances ? I did not see any such flag=
s 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 d=
escription did not match.
Thanks,
Srijith.
--_000_CH2PR18MB3270B7155D3E2949CEEE11C7E9EA0CH2PR18MB3270namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-IN" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi All,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"> &nbs=
p; We recently upgraded our application to log4j 2.13 fro=
m log4j 1.2.15. Since the upgrade, we’ve noticed in one of our test s=
etups that the application is running out of heap space. Upon inspecting th=
e heap dump, we found that
there are almost a 100 thousand entries in the HashMap owned by AbstractMa=
nager instance. Upon further investigation of the heap dump, we were able t=
o 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 d=
ifferent patterns during logging and the Pattern Layout is invoking the ini=
t 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 Con=
sole Appender instances are garbage collected later or turn off the creatio=
n of these Default Console Appender instances ? I did not see any such flag=
s to stop this in the code but still
wondering if we really need to have so many instances loaded in memory.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"> &nbs=
p; I’ve attached the leak report here. Not attaching the heap dump, b=
ecause I have some proprietary information on it. Saw a reference to
<a href=3D"https://issues.apache.org/jira/browse/LOG4J2-1176">https://issue=
s.apache.org/jira/browse/LOG4J2-1176</a> in the code, but the problem descr=
iption did not match.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">Srijith.<o:p></o:p></p>
</div>
</body>
</html>
--_000_CH2PR18MB3270B7155D3E2949CEEE11C7E9EA0CH2PR18MB3270namp_--
--_004_CH2PR18MB3270B7155D3E2949CEEE11C7E9EA0CH2PR18MB3270namp_--