Problem with Applet, Reload and Threadgroup

[rino_salvade]

We va an applet that connects to a topic on JBossMQ. Everthings works fine so far. The only problem is with the reload. When we click on the reload button we get the following exception


org.jboss.mq.SpyJMSException: Exiting on unexpected error in read task; - nested throwable: (java.lang.reflect.UndeclaredThrowableException)
at org.jboss.mq.Connection.asynchFailure(Connection.java:436)
at org.jboss.mq.il.uil2.UILClientILService.asynchFailure(UILClientILService.java:147)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleStop(SocketManager.java:400)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:342)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.reflect.UndeclaredThrowableException
... 4 more
Caused by: java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at java.lang.ThreadGroup.stopOrSuspend(Unknown Source)
at java.lang.ThreadGroup.stopOrSuspend(Unknown Source)
at java.lang.ThreadGroup.stop(Unknown Source)
at sun.awt.AppContext.dispose(Unknown Source)
at sun.applet.AppletClassLoader.release(Unknown Source)
at sun.plugin.security.PluginClassLoader.release(Unknown Source)
at sun.applet.AppletPanel.release(Unknown Source)
at sun.applet.AppletPanel.sendEvent(Unknown Source)
at sun.plugin.AppletViewer.onPrivateClose(Unknown Source)
at sun.plugin.AppletViewer$1.run(Unknown Source)


Having had a look at the source code it seems to me that the static thread group in the Connection might cause the problem. Even so it is created from new when it is destroyed I do have the feeling that there is a timing problem, i.e. that the new read task of the SocketMgr is part of the thread group of the old connection since the thread group is only destory after the last one of its thread is destroyed.

We use the standard code to close the connection in the destroy method

connection.stop();
messageConsumer.close();
session.close();
connection.close();

Is there a way to force the connection to release the threadgroup of any other workaround

Currently we're using JDK 1.5.0, JBoss 4 and IE 6

[genman]

Feel free to modify the JBoss 4 code and post a patch to sf.net . I'm not entirely sure how ThreadGroup.destroy can help you, and even if it did I don't have an applet environment to test a fix.

[rino_salvade]

I have a patch in the meantime which I'm testing. To my understanding the problem is caused that during the reload the static thread group is not yet destroyed when the new Applet is loaded and that therefor its threads are as well attached to the static threadgroup and are then destroyed (but this is a wild guess).
So I made a patch which uses a thread group per connection. By this I'm sure that there are no mixups. However for that I had to some classes in the org.jboss.mq.il.* packages so that the **ServerIL classes get the right connection to get the thread group from.
So far this works fine with the exception of the HAIServerIL in the cluster group. For this I haven't found a way yet to pass the connection.
Putting the patch on SF is a little difficult since I downloaded the sources for jboss 4.0.0, but if I compile them the jbossall-client.jar is slightly different in its size than the one from the binary distribution (maybe compiler options?). I tried as well to get the soureces from the cvs server (jboss-head) but got a strange directory structure which would not compile. Additionally when I compile the sources (the standard ones for 4.0.0) and run the tests I get a lot of failures (about 300). So I'm a little bit reluctant to pass the patch on before I have an environment which I feel confident with.

By the way, this is maybe a silly question, but what is the reason to have a threadgroup anyway? To my understanding the JVM in the plugin provides a standard one per applet thread. Is there a special reason for this thread group?

[starksm64]

You can post the patch as it will be validated.

The ThreadGroup simply categorizes all of the jms thread into a logical grouping.

[rino_salvade]

I do understand that the thread goup categorizes the jms threads. It's just so that I haven't seen any code which makes use of this situation, so its seems to be more a question of the concept than of a real usefulness. If that was the case I could easily replace the implementation of static method getThreadGroup of the connection with something like Thread.currentThread().getThreadGroup()., which would make the correction much easier.
Anyway I will post what I have done over the weekend.