Bugs item #674432, was opened at 2003-01-24 18:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=674432&group_id=22866

Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Stefan Reich (sreich)
Assigned to: Scott M Stark (starksm)
Summary: lock starvation with Ecperf

Initial Comment:
I ran Ecperf on JDK 1.4.1 on MacOSX with CMP deployment on Jboss 3.0.6 latest from 
today. The test stopped after a while. I was only able to reproduce it once so far, 
with the -Xint flag. I got one thread with the following trace:

"RMI TCP Connection(127)-17.205.41.241" daemon prio=5 tid=0x04b88490 nid=0x4b23c70 in 
Object.wait() [f98ac000..f98b0b70]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x5d3996f0> (a org.jboss.mx.loading.ClassLoadingTask)
        at java.lang.Object.wait(Object.java:426)
        at org.jboss.mx.loading.LoadMgr.nextTask(LoadMgr.java:229)
        - locked <0x5d3996f0> (a org.jboss.mx.loading.ClassLoadingTask)
        at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:165)
        - locked <0x5aa54640> (a org.jboss.mx.loading.UnifiedClassLoader3)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
        - locked <0x5aa54640> (a org.jboss.mx.loading.UnifiedClassLoader3)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:140)
        at com.sun.ecperf.ruleengine.CachedClass.<init>(CachedClass.java:44)
        at com.sun.ecperf.ruleengine.ClassCache.forName(ClassCache.java:61)
        at 
com.sun.ecperf.ruleengine.RuleProcessor.firstIdentifier(RuleProcessor.java:5487)
        at com.sun.ecperf.ruleengine.RuleProcessor.evalName(RuleProcessor.java:5682)

Another thread waiting on the first thread had the lock to class loader instance 
0x5aa54640:

"RMI TCP Connection(203)-17.205.41.241" daemon prio=5 tid=0x04bc4ad0 nid=0x4b2fdc0 
waiting for monitor entry [fbefb000..fbefcb70]
        at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:120)
        - waiting to lock <0x5aa54640> (a org.jboss.mx.loading.UnifiedClassLoader3)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
        - locked <0x5ac4ce88> (a org.jboss.web.WebClassLoader)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
        - locked <0x5ac4a248> (a java.net.URLClassLoader)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at 
org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:37)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)


All other threads were blocked waiting on the lock for the classloader 0x5ac4a248:

"RMI TCP Connection(128)-17.205.41.241" daemon prio=5 tid=0x04b89010 nid=0x4b23ed0 
waiting for monitor entry [f9930000..f9931b70]
        at java.lang.ClassLoader.loadClass(ClassLoader.java:288)
        - waiting to lock <0x5aa5c288> (a java.net.URLClassLoader)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at 
org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:37)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
        at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78)

I have a 50MB log about the class loading details. The only noteworthy event in the 
last entries in the log file was this exception:

[856915,LoadMgr,RMI TCP Connection(127)-17.205.41.241] nextTask(WAIT_ON_EVENT), 
interrupted
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:426)
        at org.jboss.mx.loading.LoadMgr.nextTask(LoadMgr.java:229)
        at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:165)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:140)


----------------------------------------------------------------------

>Comment By: Stefan Reich (sreich)
Date: 2003-01-27 18:40

Message:
Logged In: YES 
user_id=429729

Log file sent to Scott.
The problem is fairly reproducable on my Dual 500 PowerMac with JDK 1.4.1 if you run 
the VM with -Xint.

----------------------------------------------------------------------

Comment By: Scott M Stark (starksm)
Date: 2003-01-25 00:27

Message:
Logged In: YES 
user_id=175228

The RMI threads waiting on the class loader are just 
byproducts of the load notify that is causing the RMI TCP 
Connection(127)-17.205.41.241 to hang. Zip up the log file 
and send it to [EMAIL PROTECTED] as I need to look into 
what thread should have sent the notification.

Its probably a bad thing to ignore the InterruptedException so 
this has been changed to abort the loadClass call. Please 
retry this this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=674432&group_id=22866


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to