Bugs item #482875, was opened at 2001-11-17 12:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=482875&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
>Resolution: Works For Me
Priority: 7
Submitted By: Joel Boehland (jolby)
>Assigned to: Scott M Stark (starksm)
Summary: OutOfMemory after many Deploy cycles
Initial Comment:
I have been seeing OutOfMemoryErrors in my server after
doing several deploy/redeploy cycles of my application
.ear file (which is around 3 megs in size)
Basic info:
*Hardware: AMD-K2-400MHz, 196MB RAM
*OS: linux 2.2.14
*jdk: Blackdown-1.3.0-FCS, mixed mode
*Server: JBoss-2.4.3_Jetty-3.1.3-1
*ServerTrace: I don't have one now, but I can provide
one later if needed.
*Steps to reproduce: Deploy/Redeploy .ear file many
times. My .ear is around 3 megs, so it may be necessary
to use a large one to trigger this effect.
Other info
*I have had this happen using native threads mode, and
green threads mode.
*"Jozsa Kristof" <[EMAIL PROTECTED]> has also reported
this error on the jboss-user list. He was using IBM jdk
1.3.0 on linux, so this doesn't appear to be tied to
any particular version of the jdk.
--Joel
----------------------------------------------------------------------
>Comment By: Scott M Stark (starksm)
Date: 2001-11-26 18:37
Message:
Logged In: YES
user_id=175228
I can't reproduce this behavior on a RedHat 7.2(2.4.7-10)
using the Sun 1.3.1_01 JDK or on a Win2ksp2 system running
the Sun 1.3.1_01 JDK using the latest 2.4 branch code that
will be released as 2.4.4. On the Win2k system I am running
with JBoss under OptimizeIT using -Xms20m -Xmx24m and the
heap stays at 20M and the heap usage ranges between 5M and
12M. I have redeployed the 14k bank.jar from the jbosstest
suite 100 times and still see no hint of OutOfMemory
problems.
----------------------------------------------------------------------
Comment By: Adrian Brock (ejort)
Date: 2001-11-25 07:04
Message:
Logged In: YES
user_id=9459
Hang on, there's more to it than this.
I was testing it with the JMX Adapter and EJB management
beans on V3.
When I retested it with HelloWorld.jar I still got the
OutOfMemory.
----------------------------------------------------------------------
Comment By: Adrian Brock (ejort)
Date: 2001-11-25 06:27
Message:
Logged In: YES
user_id=9459
Located the problem.
org.jboss.naming.ENCFactory
is holding a hard link to the classloader in a static
Hashtable (encs).
Changing encs to a WeakHashMap fixes the problem.
This works because when nobody is using the classloader
(i.e. all classes unloaded and other hardlinks such as the
web server are removed) it will be removed from the
WeakHashMap by the garbage collector.
Two points.
1) WeakHashMap was introduced in 1.2, is it ok to use it in
JBoss?
2) I don't have CVS access to fix this, could somebody look
at it and apply the fix?
Regards
Adrian
----------------------------------------------------------------------
Comment By: Adrian Brock (ejort)
Date: 2001-11-19 07:55
Message:
Logged In: YES
user_id=9459
I can reproduce this with a 4k HelloWorld.jar using the
-Xmx parameter to constrain the heap size of the JVM.
It seems the classloaders created by J2EEDeployer are not
being garbage collected.
Here's a hack to monitor garbage collection from
org.jboss.Main.
You call org.jboss.Main.monitorGarbage(Object,String) to
request monitoring and the list of uncollected stuff gets
printed once a second.
System.out.println("JBoss "+versionIdentifier+" Started
in "+minutes+"m:"+seconds+"s");
<hack>
try
{
while (true)
{
// Wait for garbage collection
java.lang.ref.Reference collected =
garbageQueue.remove(1000);
while (collected !=null)
{
// Remove all available garbage
garbage.remove(collected);
collected = garbageQueue.remove(1);
}
// List uncollected garbage
Iterator uncollected = garbage.values().iterator();
System.out.println("Uncollected items: " +
garbage.size());
while (uncollected.hasNext())
System.out.println(uncollected.next());
System.gc();
}
}catch (InterruptedException ignored){};
</hack>
}
<resume-hack>
// Request garbage collection monitoring
public static void monitorGarbage(Object object,
String info)
{
garbage.put(
new java.lang.ref.WeakReference(object,garbageQueue),
info);
System.out.println("MonitorGarbage: " + info);
}
// Garbage to monitor
public static HashMap garbage = new HashMap();
// Garbage collected queue
public static java.lang.ref.ReferenceQueue garbageQueue =
new java.lang.ref.ReferenceQueue();
</resume-hack>
Then I changed org.jboss.deployment.J2EEDeployer
to monitor the garbage collection of the classloader
// set the context classloader for this application
createContextClassLoader(_d);
// save the application classloader for later
ClassLoader appCl =
Thread.currentThread().getContextClassLoader();
<new-code>
org.jboss.Main.monitorGarbage(appCl, "ClassLoader " +
_d.getName());
</new-code>
If you go through the cycle of deploying and undeploying a
few times you'll notice the the classloaders are never
garbage collected.
There must be a class lying around somewhere that needs the
classloader?????
----------------------------------------------------------------------
Comment By: Jim Cook (oravecz)
Date: 2001-11-17 14:42
Message:
Logged In: YES
user_id=6215
Ditto, on Windows 2000 as well. Redeploy of a 700K WAR file
causes an Out of Memory after 15-20 redeploys.
Would there be any clues as to whether the WAR file
contents are actually guilty of some kind of memory leak?
Using WebWork and Velocity in the WAR...
-jim
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=482875&group_id=22866
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
