Hello,
I come back again with my old trick that hadn't much success in the past.
To solve the system class loader problem definitivly, at least with JDK 1.4
and upper, why not use the "java.system.class.loader" system property (see
javadoc of java.lang.Classloader.getSystemClassLoader).
This way, we could have a "Fake Classloader", let's call it a
"RedirectorClassLoader" (RCL), registered as the system classloader. When a
call originates from a UCL, the RCL would do its normal work. But when a
call doesn't come from a UCL, the RCL would check what is the current
"contextual" UCL (as we could/can have multiple UCLs) and delegate the
loading to this UCL.
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> [EMAIL PROTECTED]
> Envoyé : mercredi, 2 octobre 2002 18:06
> À : [EMAIL PROTECTED]
> Objet : [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
>
>
> Bugs item #617574, was opened at 2002-10-02 16:20
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=376685&aid=61757
> 4&group_id=22866
>
> Category: JBossMX
> Group: v3.2
> Status: Open
> Resolution: None
> Priority: 7
> Submitted By: Michael Bartmann (bartmann)
> Assigned to: Scott M Stark (starksm)
> Summary: Classloader deadlock
>
> Initial Comment:
> We have for the third time in quite some weeks
> experienced a partial lookup
> of the JBoss server (some services responsive, others
> not). The bug is not deterministically reproducible for us.
> But this time we luckily had a debugger online and
> drilled down
> to what seems to be a classloader deadlock.
>
> This was under NT4.0 (it happend before under W2000 also)
> We used Branch_3_2 (checkout 12 hours before it went beta)
> under JDK1.4.0-b92.
>
> It happened when many separate ear-scoped mbeans
> and dependent MDBs got deployed in a short time.
> Many of the mbeans are JMSProviders and the MDBs
> recieve external messages almost immediatelly after
> startup, so they all try to load classes simultaneously.
>
> Most of the threads were waiting for a lock at line 84
> in the loadClass()
> of HeirarchicalLoaderRepository2; only one threads was
> locked
> in loadClass() of java.lang.ClassLoader.
>
> The two threads which seem to have caused the deadlock were
> "Thread-47" (java.util.TimerThread) and
> "Thread Pool Worker-0" (EDU.oswego.blablaWorker),
> both childs of the ThreadGroup "ASF Session Pool Threads".
>
> ===================================
> "Thread-47" has the following trace:
> loadClass() at line 84 of
> org.jboss.mx.loading.HeirarchicalLoaderRepository2,
> this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
> ...
> loadClass() at line 262 of java.lang.ClassLoader,
> this=org.jboss.mx.loading.UnifiedClassLoader@1299
> ...
> ===================================
> "Thread Pool Worker-0" has the following trace:
> loadClass() at line 295 of java.lang.ClassLoader,
> this=org.jboss.mx.loading.UnifiedClassLoader@1299
> ...
> loadClass() at line 88 of
> org.jboss.mx.loading.HeirarchicalLoaderRepository2,
> this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
> ...
> ===================================
>
> ...so the deadlock seems evident.
>
>
> ----------------------------------------------------------------------
>
> >Comment By: Michael Bartmann (bartmann)
> Date: 2002-10-02 18:05
>
> Message:
> Logged In: YES
> user_id=69300
>
> Hi Adrian,
> you are right, only one of the threads goes through UCL2.
> The other one (initiating in java.util.TimerThread) goes there
> right throug the guts of some sun classes.
> I'll append stacktraces in the (sorry for that) format of
> zipped screenshots of the jbuilder debugger gui; there was
> no way to save them as text :-(
> Regards,
> Michael
>
>
> ----------------------------------------------------------------------
>
> Comment By: Michael Bartmann (bartmann)
> Date: 2002-10-02 17:58
>
> Message:
> Logged In: YES
> user_id=69300
>
> Hi Adrian,
> you are right, only one of the threads (the one from
> the MBean container) goes through a UCL2. The other one
> is an offspring of java.util.TimerThread and gets there right
> through the guts of some sun classes. I have detailed
> stacktraces as JBuilder-screenshot-bitmaps, which I will
> append here (one at a time, I don't know how to append more
> than one file through the sourceforge bug tracker)
> Enjoy,
> Michael
>
> ----------------------------------------------------------------------
>
> Comment By: Adrian Brock (ejort)
> Date: 2002-10-02 17:40
>
> Message:
> Logged In: YES
> user_id=9459
>
> Hi Michael,
>
> Does this appear in your stacktrace?
>
> package org.jboss.jms.asf;
> ...
> public class ServerSessionPoolLoader
> ...
> protected void startService() throws Exception
> {
> XidFactoryMBean xidFactoryObj = (XidFactoryMBean)
> getServer().getAttribute(xidFactory, "Instance");
>
> Class cls = Class.forName(poolFactoryClass);
>
> I've seen stack traces where Class.forName goes
> straight through loadClassInternal() with the known
> synchronization bug.
>
> Shouldn't this use the context cl, a UCL2?
>
> Regards,
> Adrian
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=376685&aid=61757
4&group_id=22866
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
