I brought this thing back to life and passed the URL of the orginal sun
bug that they rejected. Here is a quick stack trace of the deadlock.
Note that you should start jboss with the -Xdebug options so it shows
you what objects that it is trying to lock. See below for my orginal
post


"CCRAPoll" prio=5 tid=0x8184f58 nid=0x64ec waiting for monitor entry
[0xbb7fe000..0xbb7ffad8]
        at java.lang.ClassLoader.loadClass(ClassLoader.java:288)
        - waiting to lock <43a2c508> (a
org.jboss.mx.loading.UnifiedClassLoader)
        at
org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java:180)
        at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderRepository.java:178)
        at
org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:217)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
        - locked <43eefa48> (a org.jboss.mx.loading.UnifiedClassLoader)
        at
com.entrust.toolkit.PKCS7EncodeStream.e(PKCS7EncodeStream.java)
        at
com.entrust.toolkit.PKCS7EncodeStream.f(PKCS7EncodeStream.java)
        at
com.entrust.toolkit.PKCS7EncodeStream.write(PKCS7EncodeStream.java)
        at com.candata.gateway.Encryption.Sign(Unknown Source)
        - locked <43f0c6a0> (a com.candata.gateway.Encryption)
        at com.candata.gateway.Encryption.createMsg(Unknown Source)
        at com.candata.gateway.CCRAAbstract.postMsg(Unknown Source)
        at com.candata.gateway.CCRAAbstract.recvMsg(Unknown Source)
        at com.candata.gateway.CCRAPoll.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:484)


"Thread-20" prio=5 tid=0x81821a8 nid=0x64f9 waiting for monitor entry
[0xbe7fe000..0xbe7ffad8]
        at java.lang.ClassLoader.loadClass(ClassLoader.java:288)
        - waiting to lock <43eefa48> (a
org.jboss.mx.loading.UnifiedClassLoader)
        at
org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java:180)
        at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderRepository.java:178)
        at
org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:217)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
        - locked <43a2c508> (a org.jboss.mx.loading.UnifiedClassLoader)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:195)
        at
javax.security.auth.login.LoginContext.invoke(LoginContext.java:626)
        at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
        at
javax.security.auth.login.LoginContext$4.run(LoginContext.java:599)
        at java.security.AccessController.doPrivileged(Native Method)
        at
javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:596)
        at
javax.security.auth.login.LoginContext.login(LoginContext.java:523)
        at com.candata.util.beans.CandataClientLogin.login(Unknown
Source)
        at com.candata.bbxinterface.BbxJavaInvoker.login(Unknown Source)
        at com.candata.bbxinterface.BbxWrapper.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:484)



On Mon, 2002-04-22 at 14:49, marc fleury wrote:
> |The players:
> |UnifiedClassLoader A (can load directly class foo)
> |UnifiedClassLoader B (can load directly class bar)
> |
> |Thread 1 (context loader is A):
> |  Load new class bar:
> |    - synchronize on UCL A
> |    - Search UCL B
> |    - Attempt to synchronize on UCL B
> |
> |Thread 2 (contect loader is B):
> |  Load new class foo:
> |    - synchronize on UCL B
> |    - Search UCL A
> |    - Attempt to synchronize on UCL A
> |
> |Can someone verify if this is accurate?
> 
> If this is the case this is simple to solve, just synchronize on the
> repository and thus enforce a single thread mode.  Trivial, dead problem.
> Unfortunately I don't think that was the scenario that led to deadlocks but
> I dont' remember as Sacha and Jung were the ones that got it... but if that
> is the case that is fairly simple to solve... I can't remember and would
> rather not stay in the uncertain land.  Where does the "loadClassInternal()"
> intervene?
> 
> marcf
> 
> 
> 
> _______________________________________________
> 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

Reply via email to