ll 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-d
rü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:
> |
> |
@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 re
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
-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 o
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 fi
|Also ClassLoader.loadClass(String, boolean) is sync'ed. It's not a
|problem of loadClassInternal IMHO.
|Also the UCL at the end calls super.loadClass() (in
|loadClassLocally()) so...
right so it is just a problem with synchronized cls...
I will try the solution I am thinking of.
hey quick ques
l 22, 2002 5:47 PM
To: David Maplesden; Jboss-Development@Lists. Sourceforge. Net
Subject: RE: [JBoss-dev] Workaround for CL stuff
Ok...
I think I see,
but then there might be a solution which is to sleep one of the thread
which will release the lock for that we need detection at the ULR level
o
|You have 2 threads, both waiting for something, just started, so
|not classes have been loaded yet. (see Dave Smith post for stack
|trace and example).
|Thread "CCRAPoll" (call it Encryption thread) asks the CtxCL to
|load something. CtxCL is some JBoss UCL.
|Other thread is "Thread-20" (call it
Hi,
> The major problem (and the starting point of the whole thing)
> is that when
> classes are being loaded the JVM can call
> "loadClassInternal()" on multiple
> class loaders at the same time. This method is synchronized and so
> immediately two different threads have locked two different
Hi Marc,
> Simone,
>
> I still don't see the problem clearly, please help me.
Will try to do my best. I used the now "old" (thanks to you) classloader delegation
model in my project, so you probably have to integrate me with the JBoss stuff
(correct me if I'm wrong) :)
> |classloader delegat
...
thanks for the input guys
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Maplesden
|Sent: Monday, April 22, 2002 2:36 PM
|To: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Workaround for CL stu
thanks this is useful
marcf
|-Original Message-
|From: Dave Smith [mailto:[EMAIL PROTECTED]]
|Sent: Monday, April 22, 2002 12:49 PM
|To: marc fleury
|Cc: lsanders; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Workaround for CL stuff
|
|
|I brought this thing back
ystery as
all it does is call "loadClass()" which can be synchronized if it needs to
be.
David
> -Original Message-
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 23, 2002 8:47 AM
> To: Bordet, Simone; Jboss-Development@Lists. Sourc
Simone,
I still don't see the problem clearly, please help me.
|> Where does the "loadClassInternal()" intervene?
|
|It is called by the JVM when it has to resolve class dependencies.
ok
|Say you have class A that has a data member of class B.
|When a CL is asked to load A, it inspects the cla
: Monday, April 22, 2002 12:27 PM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Workaround for CL stuff
|
|
|Hi,
|
|> Where does the "loadClassInternal()" intervene?
|
|It is called by the JVM when it has to resolve class dependencies.
|
|Say you have class A th
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"
Hi,
> Where does the "loadClassInternal()" intervene?
It is called by the JVM when it has to resolve class dependencies.
Say you have class A that has a data member of class B.
When a CL is asked to load A, it inspects the class and see that it needs to load also
B. This is done at native leve
|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):
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
- A
I think one example is when you try to shut down jboss after running the
testsuite on jdk 1.4. At least this morning I got stuck and I'm pretty
sure there was a cl deadlock. It is not clear to me why shutdown would be
deadlocking here however. And this is not simple;-)
david jencks
On 2002.04
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
___
22 matches
Mail list logo
