Aw: Re: memory-leak in org.apache.jasper.compiler.Mark|Node$TemplateText

[devzero]

> 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 
org.apache.jasper.servlet.JspServlet  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" 
> An: "Tomcat Users List" 
> Betreff: Re: memory-leak in org.apache.jasper.compiler.Mark|Node$TemplateText
>
> On 04/06/2016 09:22, devz...@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  schrieb:
> > On 03/06/2016 17:14, devz...@web.de wrote:
> > 
> > You are NOT observing a memory leak.
> > 
> > 
> > 
> >> 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-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> > 
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 

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

Re: memory-leak in org.apache.jasper.compiler.Mark|Node$TemplateText

[devzero]

thanks for help - but, are you really sure?

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. 

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, 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.

is this to be expected?

regards
roland


Am 03.06.2016, 21:43, Mark Thomas  schrieb:
On 03/06/2016 17:14, devz...@web.de wrote:

You are NOT observing a memory leak.



> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


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

memory-leak in org.apache.jasper.compiler.Mark|Node$TemplateText

[devzero]

hi, 

we have a problem with our website for a while.

I tracked it down to a memory-ressource-issue due to memory-requirements for 
compiling.

We can throw memory at the problem to circumvent it, but it looks weird to me.

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).

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

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.

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 ?

Maybe the following bugreport is interesting in this context:

https://bz.apache.org/bugzilla/show_bug.cgi?id=44383

regards
Roland

ps:
Tomcat 7.0.42 and 8.0.32

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