|VM Spec 8.14
|
|Suppose that thread T has in fact performed N lock
|operations that have not been matched by unlock
|operations. The wait method then adds the current thread
|to the wait set for the object, disables the current
|thread for thread scheduling purposes, and performs N
|unlock operations to relinquish the lock.

then we have a fix...

marcf

|
|Regards,
|Adrian
|
|> |AFAIK, a thread will only release the lock in the
|> closest synchronization
|> |scope.
|>
|> hence my previous mail
|>
|> does a double synchronization on the *same* lock
|> release both or not.
|>
|> marcf
|>
|> |
|> |If you can make sure that the UCL itself is the last
|> lock before entering
|> |ULR, then it
|> |should IMHO work. Since we are not in control of
|> loadClassInternal, but of
|> |loadClass, there is the chance
|> |that this will do as wished.
|> |
|> |CGJ
|> |
|> |-----Urspr�ngliche Nachricht-----
|> |Von: marc fleury [mailto:[EMAIL PROTECTED]]
|> |Gesendet: Dienstag, 23. April 2002 03:07
|> |An: Dave Smith
|> |Cc: lsanders; Jboss-Development@Lists. Sourceforge.
|> Net
|> |Betreff: RE: [JBoss-dev] Workaround for CL stuff
|> |
|> |
|> |Solution:
|> |
|> |When a thread goes through loadClass, in the ULR we
|> "lock" with a
|> |field that
|> |tracks the thread.
|> |
|> |Another thread comes in, reaches ULR, we sync on the
|> calling CL
|> |(we know it)
|> |we wait, this releases the lock, we keep track of
|> the CL as part of this
|> |"load".  The first thread will always find a CL as
|> no CL can be locked for
|> |ever, since the thread that would reach the ULR
|> would wait.  First thread
|> |always finishes (with reentrancy so the count must
|> go on and we track the
|> |fact that it is the same thread).  When count
|> reaches 0 we get the
|> |set of CL
|> |that were touched by this thread (i.e. the set of
|> CLs that had threads in
|> |it) and we notifyAll on each element of the set,
|> start this again.
|> |
|> |Done (afaict), I will try to apply it to the stack
|> trace below.
|> |
|> ||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.loadClassLoc
|> lly(UnifiedCla
|> |ssLoader.java:180)
|> ||        at
|> ||org.jboss.mx.loading.UnifiedLoaderRepository.loadCla
|> s(UnifiedLoade
|> |rRepository.java:178)
|> |
|> |This one would reach ULR and lock the ULR, see below
|> for lock
|> |<43a2c508> NOT
|> |being locked.
|> |
|> ||        at
|> ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(Un
|> fiedClassLoade
|> ||r.java:217)
|> ||        at
|> java.lang.ClassLoader.loadClass(ClassLoader.java:255)
|> ||        at
|> java.lang.ClassLoader.loadClassInternal(ClassLoader.ja
|> a:315)
|> ||        - locked <43eefa48> (a
|> org.jboss.mx.loading.UnifiedClassLoader)
|> ||        at
|> ||com.entrust.toolkit.PKCS7EncodeStream.e(PKCS7EncodeS
|> ream.java)
|> ||        at
|> ||com.entrust.toolkit.PKCS7EncodeStream.f(PKCS7EncodeS
|> ream.java)
|> ||        at
|> ||com.entrust.toolkit.PKCS7EncodeStream.write(PKCS7Enc
|> deStream.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.loadClassLoc
|> lly(UnifiedCla
|> |ssLoader.java:180)
|> ||        at
|> ||org.jboss.mx.loading.UnifiedLoaderRepository.loadCla
|> s(UnifiedLoade
|> |rRepository.java:178)
|> |
|> |thread 2 reaches here and sees a ULR under usage. It
|> waits on the calling
|> |UCL (which we know it is passed) and THEREFORE
|> UNLOCKS <43a2c508>.
|> |
|> |Done
|> |
|> |marcf
|> |
|> ||        at
|> ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(Un
|> fiedClassLoade
|> ||r.java:217)
|> |
|> ||        at
|> java.lang.ClassLoader.loadClass(ClassLoader.java:255)
|> ||        at
|> java.lang.ClassLoader.loadClassInternal(ClassLoader.ja
|> a: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(LoginC
|> ntext.java:626)
|> ||        at
|> ||javax.security.auth.login.LoginContext.access$000(Lo
|> inContext.java:129)
|> ||        at
|> ||javax.security.auth.login.LoginContext$4.run(LoginCo
|> text.java:599)
|> ||        at
|> java.security.AccessController.doPrivileged(Native
|> Method)
|> ||        at
|> ||javax.security.auth.login.LoginContext.invokeModule(
|> oginContext.java:596)
|> ||        at
|> ||javax.security.auth.login.LoginContext.login(LoginCo
|> text.java:523)
|> ||        at
|> com.candata.util.beans.CandataClientLogin.login(Unknow
|>
|> ||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)
|> |
|> |marcf
|> |
|> |
|> |_______________________________________________
|> |Jboss-development mailing list
|> [EMAIL PROTECTED]
|> |https://lists.sourceforge.net/lists/listinfo/jboss-de
|> elopment
|> |
|> |_______________________________________________
|> |Jboss-development mailing list
|> |[EMAIL PROTECTED]
|> |https://lists.sourceforge.net/lists/listinfo/jboss-de
|> elopment
|>
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> https://lists.sourceforge.net/lists/listinfo/jboss-dev
|> lopment
|
|
|* * *
|
|View thread online:
http://jboss.org/forums/thread.jsp?forum=66&thread=13760

_______________________________________________
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