Hi Judy and Paul
On 8 April 2010 00:53, Judy Tang <Judy.J.Tang_at_sun.com> wrote:
> "I was running 1.6.0_18 yesterday and today 1.6.0_19 and I hit it both
> times."
>
> Hi Richard, You mean running the same apps in JDK 1.6.0_18 did not hit this
> issue, it only happened using JDK 1.6.0_19 ?
>
No , it seems I hit it on _16 _18 and _19
Ryan found one leave in this issue :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11110
Ryans comment (and hard work) :
One leak found.
While inspecting a memory snapshot after a series of deployments, I found an
orphaned WebappClassLoader. There was on instance associated with that loader
which had a GC root to sun.awt.AppContext.
A quick search found a similar issue in TC.
/*
* Several components end up calling:
* sun.awt.AppContext.getAppContext()
*
* Those libraries / components known to trigger memory leaks due to
* eventual calls to getAppContext() are:
*
* - Google Web Toolkit via its use of javax.imageio
* - Tomcat via its use of java.beans.Introspector.flushCaches() in
* 1.6.0_15 onwards
* - others TBD
*/
As it happens, I was using 1.6.0_15 for the testing.
I forwarded this information to Jan and he provided a fix that has been verified
(patch1.txt).
This patch was applied to 3.0 final I believe.
He says there is also a leak in Richfaces itself. I must log another issue
with JBoss.
But the app I am deploying now has nothing to do with RichFaces.
Also there is another issue :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11159
This issue is when a 5k WAR deployed 900 times breaks GlassFish
5k times 900 = 4500k
So this proves Paul's theory wrong in this case at least.
When I get time I would like to test this same app from the NetBeans in
place deploy.
I'll log another issue and attach it to this mail thread.
regards
Richard.