On 11/15/2010 12:00 PM, Christopher Dolan wrote:
Did people know about this Java bug?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4992463
It says (and related bugs say) that if you call Thread.interrupt() on a
thread that happens to be doing class loading IO at the time, then the
aborted class with thereafter yield NoClassDefFoundError.
I hadn't heard of this problem before today. My code was calling
"LookupDiscoveryManager.terminate()" too quickly after "new
LookupDiscoveryManager()" which led to:
...
I'm not aware of any possible workaround other than avoiding
Thread.interrupt() which just isn't feasible. I guess you could say
that this bug is an argument against shared classloaders, because
creating a new classloader should fix the problem (unless the NoClassDef
happened in the bootclassloader, then you're hosed).
The TestInterrupt.java program in the bug report runs correctly with the
JDK 1.6.0_22 java.
Have you tried your failing case with JDK 1.6?
As mentioned in the bug report, there is a possible workaround through
synchronization, but it would involve a lot of changes in River.
Patricia
