Re: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
Ignacio Coloma wrote: You can document it as a bug on Sun. If it really is, they can confirm it. Only take care of NOT SPEAKING ABOUT any imaginary patch :) Sun doesn't mind patches to the java.* libraries when commmitting bug reports. The also dont mind it for the purpose of internal research. But they don't want patched Java libraries floating around the net, as it violates the _one Java_ principle. If we started redistributing CGJs patch with JBoss, I think SUN would ask us to stop that. If he included it with a bug report to them, I think they would like it. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
You can document it as a bug on Sun. If it really is, they can confirm it. Only take care of NOT SPEAKING ABOUT any imaginary patch :) -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Jung , Dr. Christoph Enviado el: jueves, 04 de octubre de 2001 9:06 Para: Jboss-Development (E-Mail) Asunto: AW: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader Hi Ole others, IMHO, your nice patch has partly solved the problem, i.e., the issue that Sacha was noticing with the patch.jar NOT;-) applied. And even without patch.jar, it should have greatly diminished the deadlock possibilities ... But nevertheless, I could imagine a scenario, where a synchronized java.lang.ClassLoader.loadClassInternal() would lead to hang-ups: ServiceLibrary contains two classloaders CL1 and CL2. CL1 has class C1 and needs to loadClassInternal(C2) in Thread T1. CL2 has Class C2 and needs to loadClassInternal(C1) in Thread T2. Then there is certainly a constellation where both threads concurrently enter the classloaders, obtaining the respective CL locks and the ServiceLibrary code mutually dispatching them will block. Is that a valid scenario? CGJ -Ursprüngliche Nachricht- Von: Ole Husgaard [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 2. Oktober 2001 20:30 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader Jung , Dr. Christoph wrote: I must correct myself! We have a principle problem, unfortunately, for which I do not have an immediate answer right now: Actually, instead of synchronized(classLoaders) in ServiceLibraries, there would be the need to *atomically* synchronize on all instances of the set in order not to interfere with the ClassLoader.loadClassInternally() calls. But this is not possible with the Java synchronization mechanism, AFAIK. Please forgive me if I am wrong - I'm not very familiar with this code. But isn't the only reason for synchronizing on classLoaders that there would be problems if another thread tries to add or remove classloaders while the Set is traversed? If this is the case, couldn't we avoid synchronizing on it by making ServiceLibraries.addClassLoader() and removeClassloader() create an entire new Set? Of course, then these methods would have to be synchronized, and we would probably also have to synchronize on the instance variables classes, resources, clToClassSetMap and clToResourceSetMap, but these locks would not be held while ClassLoader.loadClassInternally() is called. 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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(J2eeDeployer.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(RMIConnectorImpl.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(URLClassLoader.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(EJBVerifier11.java:762) at org.jboss.verifier.strategy.EJBVerifier11.checkEntity(EJBVerifier11.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(J2eeDeployer.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(DeployerMBeanSupport.java:551) at org.jboss.resource.RARDeployer.deploy(RARDeployer.java:166) at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.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.
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
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
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
we though you were dead, totally assimilated... marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Bordet, Simone |Sent: Tuesday, October 02, 2001 12:53 PM |To: JBoss Development Mailing List (E-mail) |Subject: RE: [JBoss-dev] The rabbit has a bug in its pelt: |org.jboss.system.URLClassLoader | | |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 |
Re: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
Jung , Dr. Christoph wrote: I must correct myself! We have a principle problem, unfortunately, for which I do not have an immediate answer right now: Actually, instead of synchronized(classLoaders) in ServiceLibraries, there would be the need to *atomically* synchronize on all instances of the set in order not to interfere with the ClassLoader.loadClassInternally() calls. But this is not possible with the Java synchronization mechanism, AFAIK. Please forgive me if I am wrong - I'm not very familiar with this code. But isn't the only reason for synchronizing on classLoaders that there would be problems if another thread tries to add or remove classloaders while the Set is traversed? If this is the case, couldn't we avoid synchronizing on it by making ServiceLibraries.addClassLoader() and removeClassloader() create an entire new Set? Of course, then these methods would have to be synchronized, and we would probably also have to synchronize on the instance variables classes, resources, clToClassSetMap and clToResourceSetMap, but these locks would not be held while ClassLoader.loadClassInternally() is called. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
I must correct myself! We have a principle problem, unfortunately, for which I do not have an immediate answer right now: Actually, instead of synchronized(classLoaders) in ServiceLibraries, there would be the need to *atomically* synchronize on all instances of the set in order not to interfere with the ClassLoader.loadClassInternally() calls. But this is not possible with the Java synchronization mechanism, AFAIK. Puzzling, CGJ (BTW: If somebody would offer Voodoo-puppets of SUN developers in the jboss-store, you could make a fortune! If you would additionally provide JBoss-needles, you could even make a bigger one!) -Ursprüngliche Nachricht- Von: Sacha Labourey [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 1. Oktober 2001 15:04 An: Jung , Dr. Christoph Betreff: RE: Java Classloaders document Christoph, I've just read your answer and as I am not yet up-to-date with the new JBoss classloading mechanism, can't be very efficient at commenting your idea... Consequently, I am very confident in what you suggest ;) No, in fact, what you suggest seem very very possible. I may try to synchronize a method from your loading mechanism to see if it solves the problem. Which part should I synchronize? Thank you for your very effective help. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
|(BTW: If somebody would offer Voodoo-puppets of SUN developers in the |jboss-store, you could make a fortune! If you would additionally provide |JBoss-needles, you could even make a bigger one!) LOL ^ 10 listen I really want to finish the website but will try to come back to this soon (like tonight or tomorrow) If you feel like getting down... get down, get down, get down, get down don't let anybody stop you baby! marcf | | |-Ursprüngliche Nachricht- |Von: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Gesendet: Montag, 1. Oktober 2001 15:04 |An: Jung , Dr. Christoph |Betreff: RE: Java Classloaders document | | |Christoph, | |I've just read your answer and as I am not yet up-to-date with the new |JBoss |classloading mechanism, can't be very efficient at commenting your idea... |Consequently, I am very confident in what you suggest ;) | |No, in fact, what you suggest seem very very possible. I may try to |synchronize a method from your loading mechanism to see if it solves the |problem. Which part should I synchronize? | |Thank you for your very effective help. | | |___ |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
