On 07/02/2014, Mark Thomas wrote: > There is no leak. ...
Hello Mark, thank you very mych for help and your great presentation. You were absolutely right, there was no memory leak :-) Obviously there was a different issue in my application causing the leak... I'm sorry for spamming. Best regards Michal P.S. Regarding the WebappClassLoader instances I'm suprised that there is quite often an instance with started=false remaining after garbage collection is performed. However, this instace is collected later as the used perm gen memory is reaching the maximum. 2014-02-07 11:46 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 07/02/2014 06:38, Michal Botka wrote: >> Is there a way how to avoid this leak? > > There is no leak. > >> I would like to develop an application which can be safely >> deployed/undeployed without restarting the server. > > That is very much under your control. I'd suggest reading this: > http://people.apache.org/~markt/presentations/2010-08-05-Memory-Leaks-JavaOne-60mins.pdf > > as it highlights much of what can go wrong. > > >> OK, now I know that my application cannot store it's objects into >> session, but that is very strong requirement which the most of the >> applications don't meet. > > There is no such requirement. Storing objects in the session does not > trigger a memory leak on web application reload. > >> Thanks for help. >> >> 2014-02-06 22:58 GMT+01:00 David Kerber <dcker...@verizon.net>: >>> On 2/6/2014 3:13 PM, Michal Botka wrote: >>>> >>>> When an application stores an object into the session and then the >>>> application is reloaded using Tomcat Web Application Manager, the >>>> classloader cannot be garbage collected. As a result, the >>>> "OutOfMemoryError: PermGen space" error occurs after several reloads. >>> >>> >>> This is true. What is your question? > > No, this is not true. > >>>> To illustrate the issue, you can find an example below. >>>> Thanks in advance :-) > > I've taken the provided test code and confirmed - with a profiler - that > there is no memory leak. > > There is something else that is triggering your memory leak. Follow the > steps in the presentation above to find out exactly what it is that is > pinning the web application class loader in memory. > > 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
