I think there's another place in the ReentrantLock.acquire where an
InterruptedException might be thrown before the lock is acquired (and owner
set). This is the :
while (owner != null)
{
wait();
}
Perhaps a possible fix for both problems is to make acquire return a boolean (if
it didn't actually set owner or ++ holds)?
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 3, 2002 2:09 PM
Subject: [JBoss-dev] [ jboss-Bugs-563988 ] interrupted threads cannot load
classes
> Bugs item #563988, was opened at 2002-06-03 18:09
> You can respond by visiting:
>
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=563988&group_id=2286
6
>
> Category: JBossMX
> Group: v3.0 Rabbit Hole
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Harald Gliebe (hagl)
> Assigned to: Nobody/Anonymous (nobody)
> 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:
>
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
>
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=563988&group_id=2286
6
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
