If I recall correctly I have complained about the JMS Bridge swiftlet in the past and you sort of blamed the client libraries, in this case being WebSphere MQ.
The situation is as follows, for some reason the client connection cannot be established, probably without returning a valid exception or anything, I'm not sure. Anyway, the JMS Bridge swiftlet does not notice this and hangs, following swiftlets, being SNMP and JavaMail in our case, are not started at all.
If I manually edit the config of the router and disable the JMS bridges, the startup is fine.
Clicking to enable the bridge then times out, as the connection is still failing. Afterwards my confidence in normal router operation is lost, as I cannot use the explorer anymore, with mostly all operations timing out. A clean shutdown is also impossible as the JMS swiftlet can't be stopped and prevents shutdown.
Now, regardless of how good or bad a client library works I would appreciate if it was somehow possible to isolate the JMS bridge more from the main program, making it more reliable to undeploy or redeploy the entire swiftlet, to not be mostly dead if an operation within this swiftlet fails and to not hang and wait forever during startup if the swiftlet doesn't come back. I'm not sure how this could be implemented or improved, but the current situation is not very satisfactory.
We could start/stop Extension Swiftlets in a separate thread but still this thread would hang if the client lib hangs for some reason. This is all one virtual machine. So to get it working, you'd need to hard kill the router and restart it again. Killing the thread that starts an Extension Swiftlet is not a solution either. Here's the javadoc of Thread.stop():
This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.
Same problem is with enabling the bridge with Explorer. It sends a request to the Management Swiftlet which is executed in a single thread which then waits for the completion and hangs inside the client lib. Same problem!