AW: [JBoss-dev] Workaround for CL stuff

2002-04-23 Thread Jung , Dr. Christoph

Actually, it´s more complicated:

Thread 1:
VM detects that it needs bar, calls UCL A.loadClassInternal() and
hence synchronizes on A
  
Thread 2:
VM detects that it needs foo, calls UCL B.loadClassInternal() and
hence synchronizes on B

Thread 1:
UCL A delegates to Repository delegates to UCL B, LOCKED

Thread 2:
UCL B delegates to Repository delegates to UCL A, LOCKED


CGJ

-Ursprüngliche Nachricht-
Von: lsanders [mailto:[EMAIL PROTECTED]] 
Gesendet: Montag, 22. April 2002 20:29
An: Jboss-Development@Lists. Sourceforge. Net
Betreff: Re: [JBoss-dev] Workaround for CL stuff


Though I've never experienced this, I think this is the problem scenario:

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?

-Larry

 Ok,

 I am sure we can find something.

 I would appreciate a brief description of a CL deadlock scenario due 
 to
the
 final loadClassInternal. Jung? Sacha?

 It's only software, software is dumb

 marcf

 x
 Marc Fleury, Ph.D
 President and CEO
 JBoss Group, LLC
 x



 ___
 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



AW: [JBoss-dev] Workaround for CL stuff

2002-04-23 Thread Jung , Dr. Christoph

AFAIK, a thread will only release the lock in the closest synchronization
scope. 

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.loadClassLocally(UnifiedCla
ssLoader.java:180)
|at 
|org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(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(UnifiedClassLoade
|r.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(UnifiedCla
ssLoader.java:180)
|at 
|org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(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(UnifiedClassLoade
|r.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)

marcf


___
Jboss-development mailing