river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject Thread.interrupt() vs. class loading
Date Mon, 15 Nov 2010 20:00:39 GMT
Did people know about this Java bug?
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:

java.lang.AssertionError: java.lang.InterruptedException
  at net.jini.discovery.LookupDiscovery.doUnicastDiscovery(3363)
  at net.jini.discovery.LookupDiscovery.doUnicastDiscovery(3375)
  at net.jini.discovery.LookupDiscovery.access$3800(700)
  at net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.run(1758)
  at com.sun.jini.thread.TaskManager$TaskThread.run(393)
Caused by: java.lang.InterruptedException
  at net.jini.io.MarshalledInstance.get(340)
  at com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(406)
  at net.jini.discovery.LookupDiscovery$10.run(3347)
  at java.security.AccessController.doPrivileged(Unknown Source)
  at net.jini.discovery.LookupDiscovery.doUnicastDiscovery(3344)
  ... 4 more

and later:

  at net.jini.jeri.BasicJeriExporter.export(618)

I've seen several more examples and the class affected is fairly random
since it's very sensitive to timing.

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).


View raw message