Hi Charles,
Thanks for the info. I recall a post of yours I read on the Nabble list related
to this stuff so I appreciate and value your feedback.
I think I misspoke earlier. When I said the memory is still littered with the
application classes, I mean virtually everything, thousands of
From: Darryl Pentz [mailto:djpe...@yahoo.com]
Subject: Re: Tracking down OOM - PermGen using jmap and jhat
I tried using JConsole's GC button, but
clearly this didn't do the trick.
Did clicking the button run a major GC (aka PS MarkSweep)?
Are any classes at all being unloaded? (Look
: Tracking down OOM - PermGen using jmap and jhat
From: Darryl Pentz [mailto:djpe...@yahoo.com]
Subject: Re: Tracking down OOM - PermGen using jmap and jhat
I tried using JConsole's GC button, but
clearly this didn't do the trick.
Did clicking the button run a major GC (aka PS MarkSweep
From: Darryl Pentz [mailto:djpe...@yahoo.com]
Subject: Re: Tracking down OOM - PermGen using jmap and jhat
I found this thread:
http://forum.springframework.org/printthread.php?t=21383pp=40
There's a lot of real BS in that thread. There is one accurate and useful
statement:
What
I'm using this article:
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded to try and isolate
an apparent memory leak in our web application. It has been functioning fine
until a new release which we deployed over this last weekend. Now suddenly
we're hitting PermGen OOM's within the
From: Darryl Po force a entz [mailto:djpe...@yahoo.com]
Subject: Tracking down OOM - PermGen using jmap and jhat
in both cases when I run jmap/jhat the resulting output shows
the memory to still be littered with the application classes.
Which is likely the exact memory leak you're looking
