> 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" <ma...@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, 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 <ma...@apache.org> schrieb: > > On 03/06/2016 17:14, devz...@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-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
