[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=617574&group_id=22866 Category: JBossMX Group: v3.2 >Status: Open Resolution: Fixed 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-25 13:48 Message: Logged In: YES user_id=69300 The proposed fix (UCL3) hangs. See attached threaddump Regards, Michael Bartmann -- Comment By: Scott M Stark (starksm) Date: 2002-10-03 22:59 Message: Logged In: YES user_id=175228 See the changes added today to address this issue. I have not been able to come up with a testcase that reproduces the original deadlock so the completion of the fix is waiting that. -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 21:58 Message: Logged In: YES user_id=175228 Checkout the VM docs for your platform on how to generate a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT on most *unix like systems for the sun based VMs. Ok, I see what you are referring to reguarding the loadClass calls to UCL@1299. The call from Thread-47 is does not have a top level call through a UnifiedClassLoader2 at any point and this will violate the use condition for the UnfiedClassLoader entering loadClass. I'll look into that. -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 21:42 Message: Logged In: YES user_id=69300 Please forgive me. I write highly parallel code for years and don't know how to generate a VM thread dump w/o the debugger. Got to find out how. What we did instead is: we walked through the JBuilder debug thread list and saved a stacktrace of every single thread that had a loadClass anywhere in its stacktrace (as bmp, I can see you roll on the floor...). But there is one thing with your argument that I don't understand: At least in what JBuilder showed as the source of the java.lang.ClassLoader we have a lock (synchronized..) in the java.lang.ClassLoader too. So I saw two synchronized sections locking on two different ClassLoader instances, which are "overcross" in the two threads. Shouldn't this deadlock? -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 20:37 Message: Logged In: YES user_id=175228 Can't you just provide the VM thread dump rather than having to run the server in a debugger? The thread dumps shown by the two images do not indicate to me that the threads are deadlocked. The Thread Pool Worker-0 thread is in ClassLoader.loadClass with the HeirarchicalLoaderRepository2 lock held which will stop the Thread-47 from entering the HeirarchicalLoaderRepository2, but loadClass will proceed. We need the full VM thread dump in general to look at deadlock issues. The likely p
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-03 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: Fixed 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: Stephen Coy (scoy) Date: 2002-10-28 14:40 Message: Logged In: YES user_id=463096 UCL3 has broken our web application. It appears to be hanging in the same loop shown for the "main" thread in Michael's thread dump. ie. in line 152 of UnifiedClassLoader3.java -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-25 21:48 Message: Logged In: YES user_id=69300 The proposed fix (UCL3) hangs. See attached threaddump Regards, Michael Bartmann -- Comment By: Scott M Stark (starksm) Date: 2002-10-04 06:59 Message: Logged In: YES user_id=175228 See the changes added today to address this issue. I have not been able to come up with a testcase that reproduces the original deadlock so the completion of the fix is waiting that. -- Comment By: Scott M Stark (starksm) Date: 2002-10-03 05:58 Message: Logged In: YES user_id=175228 Checkout the VM docs for your platform on how to generate a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT on most *unix like systems for the sun based VMs. Ok, I see what you are referring to reguarding the loadClass calls to UCL@1299. The call from Thread-47 is does not have a top level call through a UnifiedClassLoader2 at any point and this will violate the use condition for the UnfiedClassLoader entering loadClass. I'll look into that. -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-03 05:42 Message: Logged In: YES user_id=69300 Please forgive me. I write highly parallel code for years and don't know how to generate a VM thread dump w/o the debugger. Got to find out how. What we did instead is: we walked through the JBuilder debug thread list and saved a stacktrace of every single thread that had a loadClass anywhere in its stacktrace (as bmp, I can see you roll on the floor...). But there is one thing with your argument that I don't understand: At least in what JBuilder showed as the source of the java.lang.ClassLoader we have a lock (synchronized..) in the java.lang.ClassLoader too. So I saw two synchronized sections locking on two different ClassLoader instances, which are "overcross" in the two threads. Shouldn't this deadlock? -- Comment By: Scott M Stark (starksm) Date: 2002-10-03 04:37 Message: Logged In: YES user_id=175228 Can't you just provide the VM thread dump rather than having to run the server in a debugger? The thread dumps shown by the two images do not indi
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&group_id=22866 Category: JBossMX Group: v3.2 >Status: Closed Resolution: Fixed 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: Scott M Stark (starksm) Date: 2002-10-27 19:51 Message: Logged In: YES user_id=175228 The problem was a lost class loading task notification due to non-CNFE errors during class loading. This has been fixed in the 3.0 and 3.2 branches. -- Comment By: Stephen Coy (scoy) Date: 2002-10-27 19:40 Message: Logged In: YES user_id=463096 UCL3 has broken our web application. It appears to be hanging in the same loop shown for the "main" thread in Michael's thread dump. ie. in line 152 of UnifiedClassLoader3.java -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-25 04:48 Message: Logged In: YES user_id=69300 The proposed fix (UCL3) hangs. See attached threaddump Regards, Michael Bartmann -- Comment By: Scott M Stark (starksm) Date: 2002-10-03 13:59 Message: Logged In: YES user_id=175228 See the changes added today to address this issue. I have not been able to come up with a testcase that reproduces the original deadlock so the completion of the fix is waiting that. -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 12:58 Message: Logged In: YES user_id=175228 Checkout the VM docs for your platform on how to generate a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT on most *unix like systems for the sun based VMs. Ok, I see what you are referring to reguarding the loadClass calls to UCL@1299. The call from Thread-47 is does not have a top level call through a UnifiedClassLoader2 at any point and this will violate the use condition for the UnfiedClassLoader entering loadClass. I'll look into that. -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 12:42 Message: Logged In: YES user_id=69300 Please forgive me. I write highly parallel code for years and don't know how to generate a VM thread dump w/o the debugger. Got to find out how. What we did instead is: we walked through the JBuilder debug thread list and saved a stacktrace of every single thread that had a loadClass anywhere in its stacktrace (as bmp, I can see you roll on the floor...). But there is one thing with your argument that I don't understand: At least in what JBuilder showed as the source of the java.lang.ClassLoader we have a lock (synchronized..) in the java.lang.ClassLoader too. So I saw two synchronized sections locking on two different ClassLoader instances, which are "overcross" in the two threads. Shouldn't this dead
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-03 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed 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: Stephen Coy (scoy) Date: 2002-10-28 15:28 Message: Logged In: YES user_id=463096 I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the problem is still there: "SocketListener-3" prio=5 tid=0x48620b0 nid=0x4811140 runnable [0xf0d99000..0xf0d9aba0] at java.lang.Object.wait(Native Method) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader 3.java:152) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.beans.Introspector.instantiate(Introspector.java:1061) at java.beans.Introspector.findInformant(Introspector.java:303) at java.beans.Introspector.(Introspector.java:251) at java.beans.Introspector.getBeanInfo(Introspector.java:76) at org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils .java:552) at org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j ava:516) at org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java :706) at org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java :426) at org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453) at org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB ase.java:228) at org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90) at org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona lTagBase.java:218) at JspServ.online.workList.actionBar._jspService(actionBar.java:309) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:366) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicatio nHandler.java:293) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151) at org.apache.struts.action.ActionServlet.processActionForward(ActionSer vlet.java:1759) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1596) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:366) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicatio nHandler.java:293) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:581)
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed 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: Scott M Stark (starksm) Date: 2002-10-27 20:42 Message: Logged In: YES user_id=175228 Enable tracing of the org.jboss.mx.loading category by adding a section like the following to the conf/log4j.xml file: and attach the log file of the TRACE level msgs. -- Comment By: Stephen Coy (scoy) Date: 2002-10-27 20:28 Message: Logged In: YES user_id=463096 I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the problem is still there: "SocketListener-3" prio=5 tid=0x48620b0 nid=0x4811140 runnable [0xf0d99000..0xf0d9aba0] at java.lang.Object.wait(Native Method) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader 3.java:152) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.beans.Introspector.instantiate(Introspector.java:1061) at java.beans.Introspector.findInformant(Introspector.java:303) at java.beans.Introspector.(Introspector.java:251) at java.beans.Introspector.getBeanInfo(Introspector.java:76) at org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils .java:552) at org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j ava:516) at org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java :706) at org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java :426) at org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453) at org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB ase.java:228) at org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90) at org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona lTagBase.java:218) at JspServ.online.workList.actionBar._jspService(actionBar.java:309) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:366) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicatio nHandler.java:293) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151) at org.apache.struts.action.ActionServlet.processActionForward(ActionSer vlet.java:1759) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1596) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492) at javax.servlet.http.HttpServlet.service(HttpSer
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed 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: Scott M Stark (starksm) Date: 2002-10-28 01:45 Message: Logged In: YES user_id=175228 This was another variation on a lost notification. In this case an exception thrown from LoadMgr.beginLoadTask would bypass the call to LoadMgr.endLoadTask and leave a thread assigned as the owner of a UCL when it was not. If a load task was assigned to this thread an infinite wait could ensue if the assigned thread never loaded another class. -- Comment By: Scott M Stark (starksm) Date: 2002-10-27 20:42 Message: Logged In: YES user_id=175228 Enable tracing of the org.jboss.mx.loading category by adding a section like the following to the conf/log4j.xml file: and attach the log file of the TRACE level msgs. -- Comment By: Stephen Coy (scoy) Date: 2002-10-27 20:28 Message: Logged In: YES user_id=463096 I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the problem is still there: "SocketListener-3" prio=5 tid=0x48620b0 nid=0x4811140 runnable [0xf0d99000..0xf0d9aba0] at java.lang.Object.wait(Native Method) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader 3.java:152) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.beans.Introspector.instantiate(Introspector.java:1061) at java.beans.Introspector.findInformant(Introspector.java:303) at java.beans.Introspector.(Introspector.java:251) at java.beans.Introspector.getBeanInfo(Introspector.java:76) at org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils .java:552) at org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j ava:516) at org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java :706) at org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java :426) at org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453) at org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB ase.java:228) at org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90) at org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona lTagBase.java:218) at JspServ.online.workList.actionBar._jspService(actionBar.java:309) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:366) at org.mortbay.jetty.servlet.WebApplicationHa
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-03 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed 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: Stephen Coy (scoy) Date: 2002-10-29 10:41 Message: Logged In: YES user_id=463096 This appears to be working now. -- Comment By: Scott M Stark (starksm) Date: 2002-10-28 20:45 Message: Logged In: YES user_id=175228 This was another variation on a lost notification. In this case an exception thrown from LoadMgr.beginLoadTask would bypass the call to LoadMgr.endLoadTask and leave a thread assigned as the owner of a UCL when it was not. If a load task was assigned to this thread an infinite wait could ensue if the assigned thread never loaded another class. -- Comment By: Scott M Stark (starksm) Date: 2002-10-28 15:42 Message: Logged In: YES user_id=175228 Enable tracing of the org.jboss.mx.loading category by adding a section like the following to the conf/log4j.xml file: and attach the log file of the TRACE level msgs. -- Comment By: Stephen Coy (scoy) Date: 2002-10-28 15:28 Message: Logged In: YES user_id=463096 I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the problem is still there: "SocketListener-3" prio=5 tid=0x48620b0 nid=0x4811140 runnable [0xf0d99000..0xf0d9aba0] at java.lang.Object.wait(Native Method) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader 3.java:152) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.beans.Introspector.instantiate(Introspector.java:1061) at java.beans.Introspector.findInformant(Introspector.java:303) at java.beans.Introspector.(Introspector.java:251) at java.beans.Introspector.getBeanInfo(Introspector.java:76) at org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils .java:552) at org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j ava:516) at org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java :706) at org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java :426) at org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453) at org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB ase.java:228) at org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90) at org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona lTagBase.java:218) at JspServ.online.workList.actionBar._jspService(actionBar.java:309) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
[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=617574&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Bartmann (bartmann) Assigned to: Nobody/Anonymous (nobody) 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&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
[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=617574&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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&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
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 14:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&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: Adrian Brock (ejort)
Date: 2002-10-02 15: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=617574&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
[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=617574&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=617574&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
[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=617574&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:10
Message:
Logged In: YES
user_id=69300
oops, douplicates
sourceforge didn't like my first post, I lost my text and
retried. so simply ignore one of me previous two comments.
--
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=617574&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
[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=617574&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 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=617574&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
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&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: Scott M Stark (starksm) Date: 2002-10-02 11:37 Message: Logged In: YES user_id=175228 Can't you just provide the VM thread dump rather than having to run the server in a debugger? The thread dumps shown by the two images do not indicate to me that the threads are deadlocked. The Thread Pool Worker-0 thread is in ClassLoader.loadClass with the HeirarchicalLoaderRepository2 lock held which will stop the Thread-47 from entering the HeirarchicalLoaderRepository2, but loadClass will proceed. We need the full VM thread dump in general to look at deadlock issues. The likely problem is inconsistent locking at the HeirarchicalLoaderRepository2 level which would allow for recursive calls into a HeirarchicalLoaderRepository2 by two different threads. Another change made in the 3.2 beta release that will affect this startup issue is that the TimedInstnacePoolFeeder is no longer used to initialize the pool because its start could not be synched well with the complete deployment start state. An interim workaround might be to simply remove all of the feeder config settings like the following: org.jboss.ejb.plugins.TimedInstancePoolFeeder 10 500 -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 09:10 Message: Logged In: YES user_id=69300 oops, douplicates sourceforge didn't like my first post, I lost my text and retried. so simply ignore one of me previous two comments. -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 09: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 08: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
[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=617574&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 21:42 Message: Logged In: YES user_id=69300 Please forgive me. I write highly parallel code for years and don't know how to generate a VM thread dump w/o the debugger. Got to find out how. What we did instead is: we walked through the JBuilder debug thread list and saved a stacktrace of every single thread that had a loadClass anywhere in its stacktrace (as bmp, I can see you roll on the floor...). But there is one thing with your argument that I don't understand: At least in what JBuilder showed as the source of the java.lang.ClassLoader we have a lock (synchronized..) in the java.lang.ClassLoader too. So I saw two synchronized sections locking on two different ClassLoader instances, which are "overcross" in the two threads. Shouldn't this deadlock? -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 20:37 Message: Logged In: YES user_id=175228 Can't you just provide the VM thread dump rather than having to run the server in a debugger? The thread dumps shown by the two images do not indicate to me that the threads are deadlocked. The Thread Pool Worker-0 thread is in ClassLoader.loadClass with the HeirarchicalLoaderRepository2 lock held which will stop the Thread-47 from entering the HeirarchicalLoaderRepository2, but loadClass will proceed. We need the full VM thread dump in general to look at deadlock issues. The likely problem is inconsistent locking at the HeirarchicalLoaderRepository2 level which would allow for recursive calls into a HeirarchicalLoaderRepository2 by two different threads. Another change made in the 3.2 beta release that will affect this startup issue is that the TimedInstnacePoolFeeder is no longer used to initialize the pool because its start could not be synched well with the complete deployment start state. An interim workaround might be to simply remove all of the feeder config settings like the following: org.jboss.ejb.plugins.TimedInstancePoolFeeder 10 500 -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 18:10 Message: Logged In: YES user_id=69300 oops, douplicates sourceforge didn't like my first post, I lost my text and retried. so simply ignore one of me previous two comments. -- 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.ut
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&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: Scott M Stark (starksm) Date: 2002-10-02 12:58 Message: Logged In: YES user_id=175228 Checkout the VM docs for your platform on how to generate a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT on most *unix like systems for the sun based VMs. Ok, I see what you are referring to reguarding the loadClass calls to UCL@1299. The call from Thread-47 is does not have a top level call through a UnifiedClassLoader2 at any point and this will violate the use condition for the UnfiedClassLoader entering loadClass. I'll look into that. -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 12:42 Message: Logged In: YES user_id=69300 Please forgive me. I write highly parallel code for years and don't know how to generate a VM thread dump w/o the debugger. Got to find out how. What we did instead is: we walked through the JBuilder debug thread list and saved a stacktrace of every single thread that had a loadClass anywhere in its stacktrace (as bmp, I can see you roll on the floor...). But there is one thing with your argument that I don't understand: At least in what JBuilder showed as the source of the java.lang.ClassLoader we have a lock (synchronized..) in the java.lang.ClassLoader too. So I saw two synchronized sections locking on two different ClassLoader instances, which are "overcross" in the two threads. Shouldn't this deadlock? -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 11:37 Message: Logged In: YES user_id=175228 Can't you just provide the VM thread dump rather than having to run the server in a debugger? The thread dumps shown by the two images do not indicate to me that the threads are deadlocked. The Thread Pool Worker-0 thread is in ClassLoader.loadClass with the HeirarchicalLoaderRepository2 lock held which will stop the Thread-47 from entering the HeirarchicalLoaderRepository2, but loadClass will proceed. We need the full VM thread dump in general to look at deadlock issues. The likely problem is inconsistent locking at the HeirarchicalLoaderRepository2 level which would allow for recursive calls into a HeirarchicalLoaderRepository2 by two different threads. Another change made in the 3.2 beta release that will affect this startup issue is that the TimedInstnacePoolFeeder is no longer used to initialize the pool because its start could not be synched well with the complete deployment start state. An interim workaround might be to simply remove all of the feeder config settings like the following: org.jboss.ejb.plugins.TimedInstancePoolFeeder 10
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=617574&group_id=22866 Category: JBossMX Group: v3.2 >Status: Pending >Resolution: Fixed 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: Scott M Stark (starksm) Date: 2002-10-03 13:59 Message: Logged In: YES user_id=175228 See the changes added today to address this issue. I have not been able to come up with a testcase that reproduces the original deadlock so the completion of the fix is waiting that. -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 12:58 Message: Logged In: YES user_id=175228 Checkout the VM docs for your platform on how to generate a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT on most *unix like systems for the sun based VMs. Ok, I see what you are referring to reguarding the loadClass calls to UCL@1299. The call from Thread-47 is does not have a top level call through a UnifiedClassLoader2 at any point and this will violate the use condition for the UnfiedClassLoader entering loadClass. I'll look into that. -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 12:42 Message: Logged In: YES user_id=69300 Please forgive me. I write highly parallel code for years and don't know how to generate a VM thread dump w/o the debugger. Got to find out how. What we did instead is: we walked through the JBuilder debug thread list and saved a stacktrace of every single thread that had a loadClass anywhere in its stacktrace (as bmp, I can see you roll on the floor...). But there is one thing with your argument that I don't understand: At least in what JBuilder showed as the source of the java.lang.ClassLoader we have a lock (synchronized..) in the java.lang.ClassLoader too. So I saw two synchronized sections locking on two different ClassLoader instances, which are "overcross" in the two threads. Shouldn't this deadlock? -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 11:37 Message: Logged In: YES user_id=175228 Can't you just provide the VM thread dump rather than having to run the server in a debugger? The thread dumps shown by the two images do not indicate to me that the threads are deadlocked. The Thread Pool Worker-0 thread is in ClassLoader.loadClass with the HeirarchicalLoaderRepository2 lock held which will stop the Thread-47 from entering the HeirarchicalLoaderRepository2, but loadClass will proceed. We need the full VM thread dump in general to look at deadlock issues. The likely problem is inconsistent locking at the HeirarchicalLoaderRepository2 level which would allow for recursive calls into a HeirarchicalLoaderRepository2 by two different threads. Another change made in the 3.2 beta release that will affect this startup
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=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 > > -- >
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
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
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
