Bugs item #563988, was opened at 2002-06-03 11:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=563988&group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Harald Gliebe (hagl)
>Assigned to: Scott M Stark (starksm)
Summary: interrupted threads cannot load classes
Initial Comment:
I get the following Error when deploying the attached file:
java.lang.Error: Illegal Lock usage, t=Thread[Thread-
3,5,jboss], owner=null
at
org.jboss.mx.loading.UnifiedLoaderRepository$Reentrant
Lock.release(UnifiedLoaderRepository.java:852)
at
org.jboss.mx.loading.UnifiedLoaderRepository.synchroni
ze(UnifiedLoaderRepository.java:227)
at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass
(UnifiedLoaderRepository.java:126)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClass
(UnifiedClassLoader.java:285)
at java.lang.ClassLoader.loadClass
(ClassLoader.java:262)
at java.lang.ClassLoader.loadClassInternal
(ClassLoader.java:322)
at test.TestThread.run(TestThread.java:19)
The error is caused by the
UnifiedLoaderRepository.synchronize and
unsynchronize methods that try to release the
reentrantLock even if they couldn't acquire it (i.e. if
acquire threw an InterruptedException). Further
investigations shows that the ReentrantLock throws this
exception if the incoming thread has the interrupt flag
set.
To allow class-loading in such situations (e.g. for
loadClassInternal as in the example) I changed the
synchronize and unsynchronize methods to clear the
interrupt flag before acquiring the lock and restoring it
after relesing the lock (see attached patch). This works
for the example and has no negative effects on the
TestSuite. However, I don't know what other side-effects
these changes might have.
To reproduce the exception above run the 3.0 minimal
configuration, copy test.jar to minimal/lib and test-
service.xml to minimal/deploy
Changes to UnifiedLoaderRepository:
// then on the classloader (resource ordering
problem).
// We solve this by using a reentrant lock.
+ boolean interrupted=false;
try
{
// Only one thread can pass this barrier
// Other will accumulate here and let passed one
at a time to wait on the classloader,
// like a dropping sink
+
+ // clear the interrupt flag
+ interrupted = Thread.currentThread().interrupted();
reentrantLock.acquire();
while (!isThreadAllowed(Thread.currentThread()))
@@ -225,13 +229,19 @@
// This new thread will not be allowed and will wait
() on the classloader object,
// releasing its lock.
reentrantLock.release();
+ // restore the interrupt flag
+ if (interrupted) {
+ Thread.currentThread().interrupt();
+ }
}
}
private void unsynchronize(ClassLoader cl)
{
+ boolean interrupted=false;
try
{
+ interrupted =
Thread.currentThread().interrupted();
reentrantLock.acquire();
// Reset the current thread only if we're not
reentrant
@@ -244,6 +254,9 @@
finally
{
reentrantLock.release();
+ if (interrupted) {
+ Thread.currentThread
().interrupt();
+ }
// Notify all threads waiting on this classloader
// This notification must be after the
reentrantLock's release() to avoid this scenario:
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-06-15 17:56
Message:
Logged In: YES
user_id=175228
The suggested work around makes sense and has been
applied to main and branch_3_0
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=563988&group_id=22866
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
