Hi there (got currently huge problems with our firewall, prevents a proper bug report :-(
Sascha has noticed that the RH startup process sometimes deadlocks in the new classloading scheme especially when he is starting up JavaGroups and his HA MBeans. My hypothesis (see snippets from his thread-dump below) which I´m very convinced of is: - There is some thread T1 (Jboss-Main initialising the HA Service) loading some class via a classloader CL1. That call is dispatched to the ServiceLibrary-MBean which is obtaining a monitor M1 (to ServiceLibrary.classLoaders) in order to consistently search for the class in the registered classLoaders. - There is some concurrent thread T2 (the already started Javagroups-service, I guess) loading some class lazily via CL2.loadClassInternal(String). This (private) method is synchronized on the classloader instance, thx to our beloved SUN programmers! Hence it obtains the monitor (lets call it M2) to CL2 and calls loadClass(String) which is then dispatched to the ServiceLibrary-mbean. - T1 now tries to CL2.loadClassLocally()-->java.lang.ClassLoader.loadClass() which is synchronized on CL2, hence tries to obtain M2. - T2 tries to get the monitor M1 in order to enter the ServiceLibraries class search algorithm. The problem is that f**cking private method in java.lang.ClassLoader that is unnecessarily synchronized (the following loadClass is synchronized anyway ...). A workaround could be to always lock on the ServiceLibrary.classLoaders but that may not be very efficient. Anyone got a better idea? CGJ -----Ursprüngliche Nachricht----- >Von: Sacha Labourey [mailto:[EMAIL PROTECTED]] >Gesendet: Montag, 1. Oktober 2001 13:33 >An: Jung , Dr. Christoph >Betreff: RE: Java Classloaders document ... snip ... >"DownHandler (NAKACK)" prio=5 tid=0x81d940 nid=0x9cc waiting for monitor >entry [0x99be000..0x99bfdbc] > 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(Unknown Source) > at JavaGroups.NakReceiverWindow.<init>(NakReceiverWindow.java:147) > at ... snip ... >"main" prio=5 tid=0x234f38 nid=0x878 waiting for monitor entry >[0x6e000..0x6fc34] > at java.lang.ClassLoader.loadClass(Unknown Source) > 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 >org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:151) > at sun.rmi.server.RemoteProxy.loadClassFromClass(Unknown Source) > at sun.rmi.server.RemoteProxy.getSkeleton(Unknown Source) > at sun.rmi.server.UnicastServerRef.setSkeleton(Unknown Source) > at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source) > at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source) > at java.rmi.server.UnicastRemoteObject.exportObject(Unknown Source) > at java.rmi.server.UnicastRemoteObject.exportObject(Unknown Source) > at java.rmi.server.UnicastRemoteObject.exportObject(Unknown Source) > at Here is my hypothesis: The deadlock is caused by the interaction of Thread-1 (JavaGroups) lets the VM loading some class lazily (loadClassInternal There are two threads concurrently entering the _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
