Thread group disposal question

[David Holmes - Sun Microsystems]

Hi Artem,

Artem Ananiev said the following on 08/22/08 21:43:
> Agree with you, this is definitely a problem, and I will try to resolve 
> it somehow. There is another thing which looks odd to me: stack trace 
> shows a number of AWT-EventQueue-XX threads alive. Several event 
> dispatch threads may only appear if several AppContexts exist, so I 
> assume no AppContext is correctly disposed (and no corresponding 
> ThreadGroup is destroyed). 

That depends whether at the time of the stack trace the AppContexts were 
supposed to be destroyed - I can't answer that as I don't know what was 
executing. Based on the stacktraces those event threads all like like 
they are operating normally: waiting for the next event to arrive.

And as Martin said the pool threads are there because there's a 
ThreadPoolExecutor, or in this case ScheduledThreadPoolExecutor that has 
not been shutdown. And in this case there are a great number of them, 
but it's curious the majority are pool-NN-thread-2.

Note also that the main AWT-Event-Thread-1 is also blocked on the 
AWTTreeLock.

> There is one more idea I'm going to check. It's a known fact that AWT 
> recreates its event dispatch thread if the previous one was destroyed 
> for some reason (for example, because of uncaught exception). Now 
> consider the following situation: when AppContext and its ThreadGroup 
> are being destroyed, any incoming event leads to a new dispatch thread 
> created, which in turn prevents the ThreadGroup from destroying.

I don't quite follow the logic there, but one thing you might want to 
check is which thread does the dispose of the AppContext ... if it tries 
to "stop" itself then that could be a problem. ;-)

But I'd fix the deadlock first and then see what you find. All the other 
stuff could be a result of things piling up due to the deadlock.

Cheers,
David