RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
OK, I had understood the problem was that one of the loadClass call hadn't gone *at all* through a UCL and directly went to the System classloader. my mistake. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : jeudi, 3 octobre 2002 23:02 À : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock This problem is not related to the thread context class loader. The heiarichical repositories were incorrectly synchronized and naked calls to the delegate class loaders generated by the VM were not synchronized with the repository. Both issues have been fixed. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 9:40 AM Subject: RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock Hello marc, That's not enough to simply add this: as the JVM will automatically create one instance of this class (no arg constructor), we would end up with a UCL that don't have an associated Repository. We will need to implement a new classloader that delegates loading correctly. Do you think that delegating to the context classloader is enough? In multi-Repository situations, does the current repository is correctly associated with each thread? (maybe that's one for Scott) Cheers, Sacha --- 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
RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Hello marc, That's not enough to simply add this: as the JVM will automatically create one instance of this class (no arg constructor), we would end up with a UCL that don't have an associated Repository. We will need to implement a new classloader that delegates loading correctly. Do you think that delegating to the context classloader is enough? In multi-Repository situations, does the current repository is correctly associated with each thread? (maybe that's one for Scott) Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de marc fleury Envoye : mercredi, 2 octobre 2002 20:18 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock 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). Sacha that is the solution, also it makes sure that cretins that don't delegate to context get this working properly. Can you add the System ClassLoader definition to the run scripts? thanks marc f --- 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
Re: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
This problem is not related to the thread context class loader. The heiarichical repositories were incorrectly synchronized and naked calls to the delegate class loaders generated by the VM were not synchronized with the repository. Both issues have been fixed. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 9:40 AM Subject: RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock Hello marc, That's not enough to simply add this: as the JVM will automatically create one instance of this class (no arg constructor), we would end up with a UCL that don't have an associated Repository. We will need to implement a new classloader that delegates loading correctly. Do you think that delegating to the context classloader is enough? In multi-Repository situations, does the current repository is correctly associated with each thread? (maybe that's one for Scott) Cheers, Sacha --- 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
RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
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=detailatid=376685aid=61757
4group_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,
RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Hi, 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. Not sure if your trick works with Class.forName() in all cases, especially when to go native is some JDK class such as VersionHelper12. Class.forName goes native before calling the classloader, and there it acquires the lock on the classloader; then it delegates to the classloader, which either is a UCL(2) or a child; from the UCL you walk the hierarchy up, arriving to the system classloader (or your RCL), but we already had the chance to intercept the call at UCL level. Maybe I am missing something or I misunderstood your proposal ? A feeling I have is that it is a plain old bug in HierarchyCL, but it's just a feeling (since it does not seem related to the ClassCircularityError we had in the past). Regards, Simon --- 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
RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Hello, I agree the SCL is not in play here. Why does the HeirarchicalLoaderRepository2 synchronize on itself in loadClass()? A plain UnifiedLoaderRepository2 does not. Regards, Adrian From: Bordet, Simone [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock Date: Wed, 2 Oct 2002 19:11:59 +0200 Hi, 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. Not sure if your trick works with Class.forName() in all cases, especially when to go native is some JDK class such as VersionHelper12. Class.forName goes native before calling the classloader, and there it acquires the lock on the classloader; then it delegates to the classloader, which either is a UCL(2) or a child; from the UCL you walk the hierarchy up, arriving to the system classloader (or your RCL), but we already had the chance to intercept the call at UCL level. Maybe I am missing something or I misunderstood your proposal ? A feeling I have is that it is a plain old bug in HierarchyCL, but it's just a feeling (since it does not seem related to the ClassCircularityError we had in the past). Regards, Simon --- 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 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com --- 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
RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Maybe I am missing something or I misunderstood your proposal ? A feeling I have is that it is a plain old bug in HierarchyCL, but it's just a feeling (since it does not seem related to the ClassCircularityError we had in the past). keep your feelings to yourself, you already proved incapable of solving the old bugs and just plain left them there (when it was your rewrite that was causing them). It took Scott to actually go down and solve it. Unless you have a clean analysis, something you can't produce most of the time, I don't care for your feelings on bugs. marc f --- 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
RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
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). Sacha that is the solution, also it makes sure that cretins that don't delegate to context get this working properly. Can you add the System ClassLoader definition to the run scripts? thanks marc f --- 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
Re: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Nevermid the previous reply, I thought your were talking about UnifiedLoaderRepository, not UnifiedLoaderRepository2. The self synchronization of the HeirarchicalLoaderRepository2 does look questionable. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 02, 2002 10:47 AM Subject: RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock Hello, I agree the SCL is not in play here. Why does the HeirarchicalLoaderRepository2 synchronize on itself in loadClass()? A plain UnifiedLoaderRepository2 does not. Regards, Adrian From: Bordet, Simone [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock Date: Wed, 2 Oct 2002 19:11:59 +0200 Hi, 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. Not sure if your trick works with Class.forName() in all cases, especially when to go native is some JDK class such as VersionHelper12. Class.forName goes native before calling the classloader, and there it acquires the lock on the classloader; then it delegates to the classloader, which either is a UCL(2) or a child; from the UCL you walk the hierarchy up, arriving to the system classloader (or your RCL), but we already had the chance to intercept the call at UCL level. Maybe I am missing something or I misunderstood your proposal ? A feeling I have is that it is a plain old bug in HierarchyCL, but it's just a feeling (since it does not seem related to the ClassCircularityError we had in the past). Regards, Simon --- 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 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com --- 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
Re: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Because the HeirarchicalLoaderRepository2 went from a complicated multi-level locking mechanism to ensure only a single thread was actively loading classes into the repository to a coarse single lock with delegation from the calling class loader. I'm sure this is just an issue of a access path not going through the loader repository lock. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 02, 2002 10:47 AM Subject: RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock Hello, I agree the SCL is not in play here. Why does the HeirarchicalLoaderRepository2 synchronize on itself in loadClass()? A plain UnifiedLoaderRepository2 does not. Regards, Adrian --- 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
RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
for the sake of completeness on background and context and so people don't think it is unfounded keep your feelings to yourself, you already proved incapable of solving the old bugs and just plain left them there (when it was your rewrite that was causing them). It took Scott to and then you went to the spec committee of SUN saying that the CL architecture was buggy. You snake. We heard back that noise and I truly don't appreciate you putting that complex code, keeping it broken and then telling everyone who would hear it and behind our backs that JMX on JBoss wasn't broken. All that to promote your own JMX implementation. pff... marc f --- 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
