Skip to main content

Ignored exception: java.lang.IllegalThreadStateException:

6 replies [Last post]
demonduck
Offline
Joined: 2008-03-14
Points: 0

About 1 time in 10, when stop() is called in my applet, I get:
***********
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at pangnomic.PanGnomicApplet.stop(PanGnomicApplet.java:962)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

java.lang.IllegalThreadStateException: forbid thread creation in disposed TG
at sun.plugin.security.ActivatorSecurityManager.checkAccess(Unknown Source)
at java.lang.ThreadGroup.checkAccess(Unknown Source)
at java.lang.Thread.init(Unknown Source)
at java.lang.Thread.(Unknown Source)
at java.awt.EventDispatchThread.(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.EventQueue.initDispatchThread(Unknown Source)
at java.awt.EventQueue.postEventPrivate(Unknown Source)
at java.awt.EventQueue.postEvent(Unknown Source)
at java.awt.EventQueue.invokeAndWait(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Ignored exception: java.lang.IllegalThreadStateException: forbid thread creation in disposed TG

************

It happens here while I am trying to wait() for another thread to go into it's wait state so I can kill it gracefully.

*************

public void stop()
{
if(DEBUG)
System.err.println("**STOP");
NOEVENTS = true;
synchronized (projector.lockObject)
{
try
{
NOEVENTS = true;
projector.ABORT = true;
projector.EVENT = false;
while(!projector.WAITING)
projector.lockObject.wait(); <<<<<<< happens here
if(projector.FULLSCREENMODE)
fullScreen.setFullScreenMode(false);
projector.EVENT = true;
projector.KILL = true;
projector.lockObject.notify();
}
catch (InterruptedException e1)
{
e1.printStackTrace();
NOEVENTS = false;
}
}
}

**********

Does anyone have an idea why this should happen every once in a while?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ixmal
Offline
Joined: 2004-08-08
Points: 0

It's not a best idea to ignore InterruptedExceptions... Here is what's going:

1. User closes browser page (or whatever action that leads to applet disposal).
2. Java Plugin calls stop() and then destroy(). Here your code is executed and waiting in a loop.
3. A bit later, Java Plugin stops applet's thread group. This step includes: thread group interruption, thread group disposal. If your code wouldn't ignore InterruptedExceptions, you wouldn't get IllegalThreadStateException on disposal.

demonduck
Offline
Joined: 2008-03-14
Points: 0

I don't understand what you said. I [b]don't[/b] ignore InterruptedExceptions. You see the catch block don't you?

The applet is wait()'ing when I get the IllegalThreadStateException. And I think I get the IllegalThreadStateException because the JVM kills the applet [b]WHILE [/b]I am waiting.

That seems like a bug to me.

And the reason I am wait()'ing is so I can save the state of the applet in a static variable of the applet class so if the user hits the back arrow in the browser the applet can restart easily because the lifecycle of the applet has been changed from what it was originally designed to be for some reason I don't understand. If the plugin just stop()'ped the applet when a browser page was turned like it's supposed to happen then I wouldn't have to wait() and save state as a workaround.

And now they've made the degradation of the applet lifecycle worse by just killing the applet arbitrarily.

The JVM should not kill the applet if it is in a wait state.

ixmal
Offline
Joined: 2004-08-08
Points: 0

Oh, I've just swapped some blocks in your code... Fine, you get an exception, exit the loop and stop() method. I guess that's OK and you don't consider InterruptedException as a bug, right?

As for the further IllegalThreadStateException... Agree to you, it looks like a problem in AWT. I'll file a new one in a day or two.

demonduck
Offline
Joined: 2008-03-14
Points: 0

The JVM might be sending my applet the InterruptedException because it just kills the applet while it is in a wait() state. I don't know exactly where the bug is.

It's not because of something I do in my code. My code is very simple. The stop() method is wait()'ing there for another thread to go into it's wait() state. When the other thread goes into it's wait() state, it notifies the lock object and then the stop() method proceeds.

It works most of the time. But sometimes the JVM kills and destroys the applet before the stop() method has a chance to leave it's wait() state.

I think that's the bug -- but you guys have the resources to find that out. It's beyond my resources to debug something like that.

ixmal
Offline
Joined: 2004-08-08
Points: 0

> The JVM might be sending my applet the
> InterruptedException because it just kills the applet
> while it is in a wait() state. I don't know exactly
> where the bug is.

I don't see any bug with InterruptedException. It's thrown by JVM in respond to the call to threadGroup.interrupt() - exactly according to the specification.

> It's not because of something I do in my code. My
> code is very simple. The stop() method is wait()'ing
> there for another thread to go into it's wait()
> state. When the other thread goes into it's wait()
> state, it notifies the lock object and then the
> stop() method proceeds.
>
> It works most of the time. But sometimes the JVM
> kills and destroys the applet before the stop()
> method has a chance to leave it's wait() state.

JVM doesn't kill anything, it just do what Java Plugin ask it to. Do you think Java Plugin shouldn't kill the applet if it doesn't exit its stop() method? BTW, it's clear that stop() has been finished after catching InterruptedException and then your applet is destroyed, but not while it's waiting.

> I think that's the bug -- but you guys have the
> resources to find that out. It's beyond my resources
> to debug something like that.

The problem is AWT/Swing trying to initialize a new event dispatch thread - I've just filed a new bug about this: 6809246 - it will be visible at bugs.sun.com in a few hours.

demonduck
Offline
Joined: 2008-03-14
Points: 0

> > The JVM might be sending my applet the
> > InterruptedException because it just kills the
> applet
> > while it is in a wait() state. I don't know
> exactly
> > where the bug is.
>
> I don't see any bug with InterruptedException. It's
> thrown by JVM in respond to the call to
> threadGroup.interrupt() - exactly according to the
> specification.
>

Then maybe the specification should be given a second look to modify that behavior. Just because it's in the specification doesn't mean the specification is the best way to do things. Improve the specification.

> > It's not because of something I do in my code. My
> > code is very simple. The stop() method is
> wait()'ing
> > there for another thread to go into it's wait()
> > state. When the other thread goes into it's
> wait()
> > state, it notifies the lock object and then the
> > stop() method proceeds.
> >
> > It works most of the time. But sometimes the JVM
> > kills and destroys the applet before the stop()
> > method has a chance to leave it's wait() state.
>
> JVM doesn't kill anything, it just do what Java
> Plugin ask it to. Do you think Java Plugin shouldn't
> kill the applet if it doesn't exit its stop() method?

That's exactly what I think. If my applet is in a wait() in the stop() method, then clearly I have a reason to do that. The Plugin should take that into consideration and at least delay sending the InterruptedException. If you look at the code fragment I posted, there is some code that I want to be executed [b]AFTER[/b] I leave the wait(). Instead, the InterruptedException causes those lines of code to [b]NOT BE EXECUTED[/b] and I need those lines of code to be executed so that I can store the state of the applet so that when the user comes back to the page, the applet restarts smoothly right where it left off. I repeat, what I'm doing is a workaround for the change in the lifecycle of the applet.

> BTW, it's clear that stop() has been finished after
> catching InterruptedException and then your applet is
> destroyed, but not while it's waiting.

Yes, I am aware of that and that's why I started this thread. My stop() method should not be sent an InterruptedException.

>
> > I think that's the bug -- but you guys have the
> > resources to find that out. It's beyond my
> resources
> > to debug something like that.
>
> The problem is AWT/Swing trying to initialize a new
> event dispatch thread - I've just filed a new bug
> about this: 6809246 - it will be visible at
> bugs.sun.com in a few hours.

There are two problems. The first problem is that an InterruptedException is sent to my applet while it is wait()'ing in the stop() method and the second is the problem you have filed a bug for. If your bug is fixed -- I will still have an erroneous InterruptedException sent to my stop() method.

Will you please address that issue by reviewing the specification. If you can change the entire lifecycle of the applet, you can give an applet a few seconds longer to finish it's stop() method [b]BEFORE [/b]killing the applet.