Hi,
I think I got the problem fixed with the CVS commit I made
to the org.jboss.system.ServiceLibraries class.
At least, I do not see classloader hangs any more when
running the testsuite.
Best Regards,
Ole Husgaard.
David Jencks wrote:
>
> Well I think maybe we can legally look at the code...
>
> In my (unproven) opinion the problem comes from the loadClass(name,
> resolve) method being synchronized and calling to another object within the
> synchronization. The loadClassInternal being synchronized makes no
> difference here (although I might agree it shouldn't be) since it ends up
> calling the synchronized loadClass anyway.
>
> I'm not quite sure how to reproduce the problem or make this patch idea
> work... but here is a rewritten (yet strangely invisible) loadClass that
> under no circumstances should you put into your java.lang.ClassLoader code.
> This one releases synchronization locks before calling parents, and
> reaquires it before doing anything else. Anyone want to NOT try it?
>
> david jencks
>
> protected Class loadClass(String name, boolean resolve)
> throws ClassNotFoundException
> {
> synchronized (this)
> {
> // First, check if the class has already been loaded
> Class c = findLoadedClass(name);
> if (c != null)
> {
> if (resolve) {
> resolveClass(c);
> }
> return c;
>
> } // end of if ()
> }
> //we have released the lock to call out
> try
> {
> Class c = null;
> /parent isn't going to change, I think this is ok.
> if (parent != null) {
> c = parent.loadClass(name, false);
> } else {
> c = findBootstrapClass0(name);
> }
> //get the lock back to use our own methods
> synchronized (this)
> {
> if (resolve) {
> resolveClass(c);
> }
> return c;
> }
> }
> catch (ClassNotFoundException e)
> {
> // If still not found, then call findClass in order
> // to find the class.
> synchronized (this)
> {
> Class c = findClass(name);
> if (resolve) {
> resolveClass(c);
> }
> return c;
> }
> }
> }
>
> On 2001.10.03 10:18:21 -0400 "Jung , Dr. Christoph" wrote:
> > Hi there,
> >
> > In order to verify whether our hypothesis about that ugly deadlocking
> > behaviour of the RH classloaders is right
> >
> > (Sascha, Simone and Ole seem to have some serious problems in that
> > direction, if I understood their postings right),
> >
> > could you please NOT try out the following patch.jar (the synchronized
> > modifier has been removed at Class
> > java.lang.ClassLoader.loadClassInternal(String), which is IMHO a totally
> > uncritical) which violates the
> > Sun Binary Code License!
> >
> > Hence, do NOT start jboss using java -Xbootclasspath/p:patch.jar ...
> >
> > CGJ
> >
> >
> > <<patch.jar>>
> >
> >
> >
>
> _______________________________________________
> 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
