Hey, got similar (I would say the same) problem for a project I'm working on. I don't know well the code in ServiceLibrary, but be aware also that because of the delegation mechanism of java classloaders, this may happens as well: CL2 is child of CL1; CL2 is asked to load clsA and delegates its parent CL1; unfortunately in doing so, the locks for both CL2 and CL1 are now held by this thread. If you have another thread that starts to load classes from CL1 and then asks something to CL2 (for example because CL2 is the context CL), then deadlock is possible.
Bear in mind also that loadClassInternal is called by the JVM to load dependent classes. The JVM specification explicitely says that if class clsA was loaded by CL1 then any class referenced by clsA will be loaded by CL1 through loadClassInternal (JVMS 5.3), completely skipping the CL hierarchy. So, if you don't have loaded yet all your classes, at any time you can find a loadClassInternal that jumps in at an arbitrary point of the CL hierarchy, potentially causing deadlocks. Hope the above may help (maybe you all already knew about), but I found no solution for this problem: due to time constraints of my project I decided to go the simple way and have the problematic classes be loaded by the same CL. Anyway I wrote a very simple debugging class that uses JDI to understand deadlocks (who is holding what, and the list of what is waiting for, normal debuggers don't give this informations :), if you think that may help I can share it. A feeling I have is that not everything should be loaded explicitely by the context CL, but also using the old Class.forName (that uses the caller's CL, as loadClassInternal does). This will avoid the CL locking on all the CL hierarchy. Maybe carefully using the TCCL and Class.forName will give some result (but sure it's a pain to pay so much attention just to load a class). If anyone finds a solution, please let the list know, thanks :) Anyhow, veery interesting indeed. Simon > I must correct myself! We have a principle problem, > unfortunately, for which > I do not > have an immediate answer right now: > > Actually, instead of synchronized(classLoaders) in > ServiceLibraries, there > would be the need > to *atomically* synchronize on all instances of the set in > order not to > interfere with the ClassLoader.loadClassInternally() calls. > > But this is not possible with the Java synchronization > mechanism, AFAIK. > > Puzzling, > CGJ > > (BTW: If somebody would offer Voodoo-puppets of SUN developers in the > jboss-store, you could make a fortune! If you would > additionally provide > JBoss-needles, you could even make a bigger one!) > > > -----Ursprüngliche Nachricht----- > >Von: Sacha Labourey [mailto:[EMAIL PROTECTED]] > >Gesendet: Montag, 1. Oktober 2001 15:04 > >An: Jung , Dr. Christoph > >Betreff: RE: Java Classloaders document > > > >Christoph, > > >I've just read your answer and as I am not yet up-to-date > with the new > JBoss > >classloading mechanism, can't be very efficient at > commenting your idea... > >Consequently, I am very confident in what you suggest ;) > > >No, in fact, what you suggest seem very very possible. I may try to > >synchronize a method from your loading mechanism to see if > it solves the > >problem. Which part should I synchronize? > > >Thank you for your very effective help. > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
