You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Christopher Dolan <ch...@avid.com> on 2010/11/15 21:00:39 UTC
Thread.interrupt() vs. class loading
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:
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:
java.lang.NoClassDefFoundError
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).
Chris
RE: Thread.interrupt() vs. class loading
Posted by Christopher Dolan <ch...@avid.com>.
Agreed. This is welcome ammunition for my project to switch to 1.6.
:-)
Chris
-----Original Message-----
From: Patricia Shanahan [mailto:pats@acm.org]
Sent: Wednesday, November 17, 2010 11:28 AM
To: river-dev@incubator.apache.org
Subject: Re: Thread.interrupt() vs. class loading
You're welcome. I think it is obvious that we should *not* implement the
synchronization workaround. We do need to remain aware of the problem,
so that we can advise a switch to 1.6 if a user encounters it.
Patricia
On 11/17/2010 9:22 AM, Christopher Dolan wrote:
> Thanks very much, Patricia! I had not realized it was fixed in 1.6
(the
> original bug I linked to is still marked open).
> Chris
>
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Wednesday, November 17, 2010 4:17 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Thread.interrupt() vs. class loading
>
> 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.
> ...
>
> 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
>
Re: Thread.interrupt() vs. class loading
Posted by Patricia Shanahan <pa...@acm.org>.
You're welcome. I think it is obvious that we should *not* implement the
synchronization workaround. We do need to remain aware of the problem,
so that we can advise a switch to 1.6 if a user encounters it.
Patricia
On 11/17/2010 9:22 AM, Christopher Dolan wrote:
> Thanks very much, Patricia! I had not realized it was fixed in 1.6 (the
> original bug I linked to is still marked open).
> Chris
>
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Wednesday, November 17, 2010 4:17 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Thread.interrupt() vs. class loading
>
> 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.
> ...
>
> 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
>
RE: Thread.interrupt() vs. class loading
Posted by Christopher Dolan <ch...@avid.com>.
Thanks very much, Patricia! I had not realized it was fixed in 1.6 (the
original bug I linked to is still marked open).
Chris
-----Original Message-----
From: Patricia Shanahan [mailto:pats@acm.org]
Sent: Wednesday, November 17, 2010 4:17 AM
To: river-dev@incubator.apache.org
Subject: Re: Thread.interrupt() vs. class loading
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.
...
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
Re: Thread.interrupt() vs. class loading
Posted by Patricia Shanahan <pa...@acm.org>.
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