Hey,
got some time and thought some more about this, which is exactly the same
problem I got in my project. Just to speak loud to clear things also to
myself.
Problem being resumed this way: 2 classloaders in chain, 2 threads
Boot
|
Ext
|
Sys
|
CL1
|
CL2
When you load something with CL2, this will delegate to its parent,
synchronizing progressively the whole chain until it finds the class. If
every class is loaded always starting from CL2 and up, then there will be no
problems: threads will wait until the one loading classes has finished.
Problem comes when thread T1 loads from CL2 up, but thread T2 loads from CL1
down. This may happen using the MLet classloader (as happens to me) or
ServiceLibraries: both have a "flat" set of CL on which they iterate to find
classes.
If T1 enters CL2, T2 enters CL1, T1 delegates to CL1 but have to wait for T2
to finish, which is waiting for CL2 to become free, hence deadlock.
To me the problem seems the 2 way lookup of classes; if it is possible
always to lookup in one direction (from bottom to top) deadlock should not
happen.
In my case I have no solution, since I use the MLet classloader; in JBoss'
case is it possible to lookup only in CL that are ancestor of the current
one ?
This would mean that MBeans cannot have circular dependencies. Is this
acceptable for current JBoss codebase or it is a too strict limit ?
I'm saying something like this in ServiceLibraries.loadClass(String,
boolean, ClassLoader)
loadClass(...)
{
// search in the cache
// not found in cache, try using asking classloader
// (should guarantee bottom-top for delegation)
// not local, try other classloaders
while (allLoaders.hasNext() && (foundClass != null))
{
cl = (URLClassLoader)allLoaders.next();
// Below the change
if (!scl.equals(cl) && cl.isAncestorOf(scl))
{
foundClass = cl.loadClassLocally(...)
}
}
...
}
where org.jboss.system.URLClassLoader can simply re-implement isAncestorOf
that is package private in java.lang.ClassLoader.
Note that it is possible that the JVM or other Java mechanism will enter the
classloader chain in the middle (loadClassInternal, RMI's
loadClassFromClass) and if the classloader hit by these automatic mechanisms
will ask one of its heir to load classes, deadlock is possible.
Unfortunately I'm not familiar with 3.0 codebase, so the above may be plain
wrong or too restrictive for JBoss.
Comments ?
Simon
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
