Jung , Dr. Christoph wrote:
Oles changes to the ServiceLibrary should perhaps (in addition to the NOT
applied patch) now lead to a successful result (Ole, when you say no
deadlocks anymore does that mean without or WITHOUT the patch? ;-)
Just with the commit i did to ServiceLibraries.java,
My impression from the problemAgain stacktrace is that there was indeed a
change in behaviour:
Thread1 does call
java.lang.ClassLoader.loadClassInternal() [instance CL1, no lock
obtained]
org.jboss.system.ServiceLibraries.loadClass() [instance SL1, no lock
obtained]
Hello David,
-Ursprüngliche Nachricht-
Von: David Jencks [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 3. Oktober 2001 21:43
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] java.lang.ClassLoader misery. Verify this
patch!
In my (unproven) opinion the problem comes from the loadClass
Hi there,
In order to verify whether our hypothesis about that ugly deadlocking
behaviour of the RH classloaders is right
(Sascha, Simone and Ole seem to have some serious problems in that
direction, if I understood their postings right),
could you please NOT try out the following patch.jar
Hey,
got some time and thought some more about this, which is exactly the same
problem I got in my project. Just to speak loud to clear things also to
myself.
Problem being resumed this way: 2 classloaders in chain, 2 threads
Boot
|
Ext
|
Sys
|
CL1
|
CL2
When you load something with CL2,
Hi,
I just rewrote the locking in ServiceLibraries.java so that
no locks are held while calling the classloaders.
Externally this file will have the same API and semantics,
but internally it is a bit different:
When adding or removing classloaders, the maps and sets
that are changed are no
Hi again,
After two successful complete test suite runs (apart from
tests that failed in the same way before) I just committed
this.
But even though I saw no problems in the tests, when
looking over the code again, I see a possible race with
lookup and classloader removal.
I think I can fix
Well I think maybe we can legally look at the code...
In my (unproven) opinion the problem comes from the loadClass(name,
resolve) method being synchronized and calling to another object within the
synchronization. The loadClassInternal being synchronized makes no
difference here (although I
Hi,
I think I got the problem fixed with the CVS commit I made
to the org.jboss.system.ServiceLibraries class.
At least, I do not see classloader hangs any more when
running the testsuite.
Best Regards,
Ole Husgaard.
David Jencks wrote:
Well I think maybe we can legally look at the
