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 cod
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 mig
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 this
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 long
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,
Hey,
> 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 t
Hello Christoph,
As you suggested, I haven't tried.
Nevertheless, I have tried to imagine what the result could have been.
Result: idem. Please find the imaginary dump stack trace.
Cheers,
Alice
> -Message d'origine-
> De : [EMAIL PROTECTED
