[ mx4j-Bugs-985335 ] HTTP Adaptor classes are not garbage collected.

Bugs item #985335, was opened at 2004-07-05 21:02
Message generated for change (Comment added) made by anoripi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=985335&group_id=47745

Category: HTTP Adaptor
Group: Release 2.0.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Trustin Lee (anoripi)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTP Adaptor classes are not garbage collected.

Initial Comment:
I made a small JMX microkernel which provides dynamic 
class reloading feature.

I registered HTTPAdaptor MBean and unregistered it, 
and then created a new class loader and registered it 
again, ...., and then I gets OutOfMemoryError.

At first, I thought it is my classloader's problem, but it 
seems to be working very fine with other MBean JARs.

I ran MX4J with debugger, and some WeakHashMap is 
holding already unregistered MBeans' classes.  I think 
HTTPAdaptor MBean has some coupling with MX4J core.

Any ideas?


----------------------------------------------------------------------

>Comment By: Trustin Lee (anoripi)
Date: 2004-07-06 10:07

Message:
Logged In: YES 
user_id=65318

I didn't look into the source code, but I could find 
WeakHashMap from my heap dump of MX4JMBeanServer:

mbeanServer= MX4JMBeanServer  (id=51)
	classLoaderRepository= 
DefaultClassLoaderRepository  (id=61)
	defaultDomain= ""
	delegate= MX4JMBeanServerDelegate  (id=66)
	delegateName= ObjectName  (id=72)
	domains= HashMap  (id=75)
	introspector= MBeanIntrospector  (id=80)
		bcelAvailable= false
		extendedMBeanInterfaces= false
		mbeanInfoCache= WeakHashMap  (id=88)
			entrySet= null
			keySet= null
			loadFactor= 0.75
			modCount= 11
			queue= ReferenceQueue  (id=91)
			size= 11
			table= WeakHashMap$Entry[16]  
(id=93)
			threshold= 16
			values= null
		mbeanInvokerCache= WeakHashMap  
(id=90)
			entrySet= null
			keySet= null
			loadFactor= 0.75
			modCount= 10
			queue= ReferenceQueue  
(id=112)
			size= 10
			table= WeakHashMap$Entry[16]  
(id=113)
			threshold= 16
			values= null
		mbeanInvokerClass= null
	invoker= MBeanServerInterceptorConfigurator  
(id=82)
	mbeanRepository= DefaultMBeanRepository  (id=85)


I can see two WeakHashMaps (whose keys are 
java.lang.Class type) are used by MX4J MBeanServer, and 
the size of the map increases over the time.  It is obvious 
that mx4j.tools.adaptor.http.HTTPAdaptor class is not GCed 
even if the classloader became unreachable by others. I 
explicitly called System.gc() many times, but the size of free 
memory (and the size of WeakHashMap, too) didn't decrease.

Strange thing is other classes from the other JARs are GCed 
when the MBean is unregistered.



----------------------------------------------------------------------

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-07-05 22:29

Message:
Logged In: YES 
user_id=128193

The HTTPAdaptor can be run inside JMXRI, so there is no
coupling with MX4J core.

Can you be more precise when you say that "some WeakHashMap
is holding already unregistered MBeans' classes" ?
Where in the MX4J code ?

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=985335&group_id=47745


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com