tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From devz...@web.de
Subject Aw: Re: memory-leak in org.apache.jasper.compiler.Mark|Node$TemplateText
Date Mon, 06 Jun 2016 10:54:54 GMT
> Then you haven't correctly set development to false or your measurement
> of used memory is not correct

you were right, i set development fals in the wrong section of web.xml.

i put it under     <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
 no, and things behave like expected.

thanks for help and sorry for the noise !


regards
roland

ps:
and indeed this should not be named memory leak, as a memory leak means indefinite ressource
grow... 


> Gesendet: Sonntag, 05. Juni 2016 um 20:14 Uhr
> Von: "Mark Thomas" <markt@apache.org>
> An: "Tomcat Users List" <users@tomcat.apache.org>
> Betreff: Re: memory-leak in org.apache.jasper.compiler.Mark|Node$TemplateText
>
> On 04/06/2016 09:22, devzero@web.de wrote:
> > thanks for help - but, are you really sure?
> 
> Yes.
> 
> > if i
> > 
> > - set development=false
> > - delete everything within work subdir to force recompile of every jsp
> > 
> > then for me, the initial crawl makes jvm consume the same amount of memory regardless
development true or false - and thats what i'm wondering about.
> 
> Then you haven't correctly set development to false or your measurement
> of used memory is not correct.
> 
> > indeed, with development=false, subsequent jsp access does not consume memory as
there is no recompile.
> > 
> > this is why this param helps workarounding the problem,
> 
> No, it isn't.
> 
> > but it does not make the memory consumption of the initial compile run go away and
i`m curious, why the initial compile run permanently leaves millions of referenced objects
in memory.
> 
> You will only see instances of Mark and TemplateText if you have not
> correctly set development to false.
> 
> Even if you set development to false, your test will still trigger
> significant memory consumption because it will trigger the loading of
> every single Servlet the JSPs have been converted into along with any
> supporting objects.
> 
> Mark
> 
> > 
> > is this to be expected?
> > 
> > regards
> > roland
> > 
> > 
> > Am 03.06.2016, 21:43, Mark Thomas <markt@apache.org> schrieb:
> > On 03/06/2016 17:14, devzero@web.de wrote:
> > 
> > You are NOT observing a memory leak.
> > 
> > <snip/>
> > 
> >> Regardless we have set "development" to true or false in
> >> conf/web.xml, , whenever i recursively crawl our website with wget
> >> (cleaning work dir before to make sure each page is being compiled
> >> again), i can easily trigger an out-of-memory condition in the JVM.
> >> When development=false, then i cannot trigger it when i did
> >> re-compile every jsp in several steps (with restarting tomcat).
> > 
> > You are not correctly configuring development to false. I have confirmed
> > the expected behaviour with a profiler when development is set to false.
> > 
> >> With VisualVM (part of jdk) i found that after wget -r crawl, there
> >> are 13 million instances of the following classes:
> >>
> >> org.apache.jasper.compiler.Mark
> >> org.apache.jasper.compiler.Node$TemplateText
> > 
> > That will only happen if development is true.
> > 
> >> My understanding from a compile run is, that it`s something which is
> >> done once and then it`s ready and done and nothing is left in
> >> memory.
> > 
> > That is not the case when development is false. The results of the
> > parsing are retaining in memory to aid the generation of useful error
> > reports.
> > 
> >> We have some ten-thousands JSPs, i`m not sure how many being crawled
> >> with wget, but i don`t get the point why i see ressources being
> >> allocated from org.apache.jasper.compiler and not being freed after
> >> compile run.
> >>
> >> Does anybody have a clue ? Is this to be expected, and if yes - why
> >> ?
> > 
> > Mark
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message