Hi Mark, I read your information, which I will quote here:
1. Find an app that you can't reload without OOME 2. Get a profiler - I like Yourkit Full disclosure: they give ASF committers a free copy 3. Reload you app once 4. Use the profiler to look for instances of WebappClassLoader 5. Look for the one with the started attribute == false 6. Trace the GC roots for this instance 7. Fix whatever is hanging on to references to the instance - there should not be any Well, I'm using Yourkit as well. I reloaded the app twice, and I found 4 instances of WebappClassLoader. Two of them correspond to my two running apps, which is correct, and the other two correspond to the leaked apps. Both of them have an instance that have the started attribute with a "false". Great, so I guess I'm in the right path to find the problem. Now I'm inspecting one of these objects with the "started=false". If I choose the report of "Paths from GC roots" from it, I see LOTS of items! And all of them have the "<loader> of" indication. All the items are classes programmed by me, so I guess I'm guilty, and not the people that programmed Tomcat ;-) . They are DTOs, facades, Struts actionforms, etc. Why are all these classes in the list? What should I check about them? Why are they still loaded? I guess there is something missing in my programming. Maybe I should do something about all the objects that are still alive that correspond to all the loaded classes? Maybe I need to do something in the "contextDestroyed()" method in the ServletContextListener in my app, in order to destroy all the objects properly? Thanks a lot for your help! Brian > -----Original Message----- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Tuesday, November 16, 2010 04:37 AM > To: Tomcat Users List > Subject: Re: After manager says that there was a leak, how to use a profiler? > > On 16/11/2010 04:12, Brian wrote: > > Maybe my question sounded too vague and repetitive. > > What I meant is something like this "Is the a class loader (or > > something like that) than I should start analyzing? I mean, is there a > > route I should follow in order to see which objects are stucked? If > > the Tomcat Manager knows that something got stucked in the memory, > how > > does it know that? Is there a clue we should start?". > > http://markmail.org/message/fcbvwapt6afyndxn > > 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
