Hi Marc,
> Simone,
>
> I still don't see the problem clearly, please help me.
Will try to do my best. I used the now "old" (thanks to you) classloader delegation
model in my project, so you probably have to integrate me with the JBoss stuff
(correct me if I'm wrong) :)
> |classloader delegates to some other classloader you can have
> deadlock.
>
> this I don't see, you seem to jump to the conclusion, can you
> please walk me?
You have 2 threads, both waiting for something, just started, so not classes have been
loaded yet. (see Dave Smith post for stack trace and example).
Thread "CCRAPoll" (call it Encryption thread) asks the CtxCL to load something. CtxCL
is some JBoss UCL.
Other thread is "Thread-20" (call it Login thread) again uses the CtxCL.
Both CLs don't know the class and delegate to the UnifiedRepository which iterates on
the CLs asking.
Same does the other thread. If you are unlucky, deadlock. Can you see it now ?
Say you have only 2 CLs
thread1 does: CL1.load("A") -> ULR.load("A"), CL1.load("A"), can't find it, iterates
on CLs (only CL2) -> CL2.load("A");
thread2 does: CL2.load("B") -> ULR.load("B"), CL2.load("B"), can't find it, iterates
on CLs (only CL1) -> CL1.load("B");
Imagine the first load is triggered by loadClassInternal() (see Encryption thread,
PKCS7EncodeStream.e() have to load some class, and loadClassInternal is called, this
syncs a JBoss UCL); the second load calls UCL.loadClassLocally() which calls super,
which is sync'ed as well :) Bang ! See it now ?
Thinking loud for a solution:
1- Resource ordering may help ? I mean if you don't iterate on CL in ULR, but first
you order them, then loop ? Not sure it will work in all cases...
2- What if you don't call super() which is sync'ed and you make other 2 UCL, one that
"wraps" jre/lib/ext and one that "wraps" the classpath, both with parent the boot CL
(ie null) ? Don't know if the boot classloader is sync'ed somewhere in native code...
Make the flat classloader space in orbit around the boot classloader, not the system
classloader...
3- The more I think the more it seems to me that if you sync all CL in the correct
order you can get out...
Kind of:
sync(cl1) {
sync(cl2) {
sync(cl3) {
..
sync(cln) {
cln.loadClass(..)
}
}
}
}
}
where cl1 < cl2 < cl3 < ... < cln and there is a clearly defined "operator <" between
classloaders (hashcode may help, is it unique when we talk of Object.hashCode() ?)
Of course since you don't know a priori the number of classloaders you have to use
some fancy Doug Lea's classes :)
Good coding, I know you like this stuff :)
Simon
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
