"ngolovin" wrote :
| What you are suggesting is exactly what I did. I saw the matrix and the duplicates.
Then I clicked on loader references and saw there approx. 2000 references (I have removed
the 200-reference limit in my copy of the references.jsp)
|
What I do is...
I - I always look for the classLoader reference.
It's hard to create a filter for this. I couldn't come up with a logic, as
sometimes a third level is what's causing a leakage. For example if you keep a
reflection reference, you will have:
reflectionObject->class->ClassLoader
And this is really hard. If you have a classLoader loading 2000 classes, and only one
class is kept referenced, all the 2000 classes will still be in the memory because of the
ArrayList on ClassLoader. (read source code from JDK you will know what I'm talking
about).
Try looking at field references first. Than move to another level.
Also.. when you said about parent classLoaders, I didn't understand what you meant.
But what usually happens is a class or an instance of that class, loaded by any different
classLoader keeping directly or indirectly a reference to your classLoader.
an example is Commons Logging. (if you're not using our patched version)
CommonsLogging will keep a HashMap of Loggers using Class as the key.
Class has the reference to the classLoader and CommonsLogging is loaded from System
ClassLoader.
I don't know if this helps...
But... as I said before.. .chasing a redeployment leakage is never fun, even if you were
using the most expensive tool.
Clebert Suconic
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967515#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...