Hey Ole, as I said I have a small tool written with JDI that will tell you who is holding what and who is waiting (so in the "wait for monitor entry" you'll know who is the monitor) If you wanna play, just tell me ;)
Simon > -----Original Message----- > From: Ole Husgaard [mailto:[EMAIL PROTECTED]] > Sent: martedi 2 ottobre 2001 18:49 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] The rabbit has a bug in its pelt: > org.jboss.system.URLClassLoader > > > Hi, > > I think this bug is the reason for the problems > we see with the automated tests. > Here the test count sometimes gets very low due > to the tests timing out. > > Looking into this is hard, as it seems to change > with every run, but one thing seems to be common: > The deployer stops working, and the timeouts > happen because all attempts at deploying beans > hang with a stack trace like: > > "RMI TCP Connection(3)-127.0.0.1" daemon prio=1 tid=0x82a5a20 > nid=0x5876 > waiting for monitor entry [0xbc7fe000..0xbc7ff8c4] > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:349) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > at > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) > at > org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye > r.java:473) > at > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > at > org.jboss.jmx.connector.rmi.RMIConnectorImpl.invoke(RMIConnect > orImpl.java:400) > at [snip] > > But I think this monitor is held by another thread > that appears hung with a stack trace like: > > "RMI TCP Connection(2)-127.0.0.1" daemon prio=1 tid=0x822fc68 > nid=0x5813 > waiting for monitor entry [0xbdffe000..0xbdfff8c4] > at java.lang.ClassLoader.loadClass(ClassLoader.java:286) > at > org.jboss.system.URLClassLoader.loadClassLocally(URLClassLoade > r.java:163) > at > org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:292) > at > org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) > at java.lang.ClassLoader.loadClass(ClassLoader.java:290) > at java.lang.ClassLoader.loadClass(ClassLoader.java:290) > at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > at > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > at java.lang.Class.getMethods0(Native Method) > at java.lang.Class.getMethods(Class.java:742) > at > org.jboss.verifier.strategy.EJBVerifier11.verifyEntityHome(EJB > Verifier11.java:762) > at > org.jboss.verifier.strategy.EJBVerifier11.checkEntity(EJBVerif > ier11.java:121) > at > org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:135) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:374) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > at > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) > at > org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye > r.java:473) > at > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) > at [snip] > > In this test run, I started the tests a little early: > After server startup was finished, but before the > autodeployer was done deploying the default rars. > Here the autodeployer seems to hang with the following > stack trace: > > "AutoDeployer" prio=1 tid=0x48d8c090 nid=0x5816 waiting for monitor > entry [0xbc3fe000..0xbc3ff8c4] > at > org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:278) > at > org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) > at > org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:151) > at > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > at > org.jboss.deployment.DeployerMBeanSupport.recursiveUnpack(Depl > oyerMBeanSupport.java:551) > at org.jboss.resource.RARDeployer.deploy(RARDeployer.java:166) > at > org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBean > Support.java:117) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > at > org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:633) > at > org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:308) > at java.lang.Thread.run(Thread.java:484) > > But even if I wait until the server is fully operational, > I see similar hangs in the test suite. > > This is complicated by the facts that: > - kill -SIGQUIT does not give a monitor dump on my > current SUN JDK 1.3.0 VM. > - The hangs seem completely random. Sometimes the > entire testsuite runs fine, and hangs at the next > run if I restart the server. But I never see a > hang on subsequent test runs if the first test run > didn't hang and I do not restart the server. Guess > that all classes have been loaded then. > > > Best Regards, > > Ole Husgaard. > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
