This permgen issue is not just a problem with Geronimo. Apache Tomcat (6 and 5) has the same issues with the permgen and continuous build integration.
When deploying to Geronimo, we first undeploy the application then redeploy. When we deploy to Apache Tomcat, we do not do an undeploy. Same results. Russell Collins Sr. Software Engineer McLane Advanced Technology "Do or do not, there is no try." - Yoda -----Original Message----- From: Quintin Beukes [mailto:quin...@skywalk.co.za] Sent: Monday, September 14, 2009 3:43 PM To: user@geronimo.apache.org Subject: Re: Starting Geronimo with More PermGen Phew. I can actually imagine ThreadLocals being a hassle in a multithreaded system regarding these leaks, as you can't really "check the value" of the "variable". Especially when the same thread type might behave differently at times. Q On Mon, Sep 14, 2009 at 9:07 PM, Kevan Miller <kevan.mil...@gmail.com> wrote: > > On Sep 14, 2009, at 1:29 PM, Quintin Beukes wrote: > >> I assume that if you have a reference to one of these classes from >> outside the application then it can prevent some classes to be GC'ed, >> like a static reference you created in some global class? Is this >> mostly the case, or is it more specialized? > > That's pretty much it. All it takes is a strong reference to any application > object (object instance, class, etc). This reference will prevent the > ClassLoader from being GC'ed. And this in turn will prevent all of the > Classes loaded by the ClassLoader from being GC'ed. These strong references > can come from ThreadLocals, statics, non-static references, or even stack > references. > > Once you've generated a .hprof file, using post-mortem analysis, you can > identify the causes of the memory leaks... > > --kevan > > -- Quintin Beukes
