Kill a stuck thread on a running virtual machine (JBoss Instance) in Java?

Question

A bug in a third-party library causes an infinite loop in the workflow on my JBoss instance. Do you know a way to kill this "stuck" thread without restarting the server? We would like to restore this until the fix is ​​deployed, preferably without a reboot.

I saw several people mentioning the use of Thread.interrupt () - if I were to encode my own MBean, how would I get the thread descriptor in question to interrupt it?

Update: Failed to resolve using any of these methods. I met another thread about the same release , in which there was a link to why Thread.stop () is deprecated . Someone else asked a similar question with similar results. It seems like more complex containers should provide such a health mechanism, but I think their hands are tied to the JVM.

Answer 1

I had a similar error (infinite loop) in third party lib. I ended up applying the fix myself (waiting for people from a third-party library to fix their clutter), and then I put the modified .class into my .war, making sure it was loaded to a dummy .class (dummy being inside a dummy third party .jar).

This is not nice, but it works, see my question here:

Class loading order from .war file

I mean the following: if you need to wait for the people responsible for the third-party listening library to fix their things, you will probably wait a very long time. We could not afford it. We needed a fix as soon as possible. So we ended up applying a patch / hack to their code.

You could, for example, add a logical check inside an infinite loop and then force the loop to end when you want the dummy thread to die.

Note that I have not used the deprecated Thread () stop since ten years, and I really did not want to use it in the above case.

Answer 2

I believe that the most difficult part is to identify the hanging thread. You do not provide information about this, but perhaps you can create some rules around the stream name or the current stack trace.

If you can identify a thread by its name, I would get all the threads in the virtual machine, getting my own thread group using Thread.currentThread().getThreadGroup() , then raise the thread group hierarchy by calling getParent() in the thread group, until it will not return null . You now have a top-level thread group. Now you can fill the pre-allocated array with all threads using the enumerate(Thread[] list) method in the top-level thread group.

If you need stack traces to identify a thread, you can also use the static utility method Map<Thread,StackTraceElement[]> Thread.getAllStackTraces() to get all the threads. Computing the stack trace, however, is quite expensive, so this might not be the best solution if you really don't need them.

After defining the stream, you must call the stop() method. Interrupting this will not help if the implementation of the executable code does not actually evaluate the thread interrupt flag and behaves as you expect. Not that the stop() method is deprecated and that using it can have a lot of funny side effects. You can find more information in the API documentation.

Answer 3

You can use the discouraged myThread.stop () method. But then it is very likely that Thread is still referencing there, so you should use reflection magic to remove all references to this thread from the components holding it.

How to find a topic? Use Thread.getThreadGroup () and ThreadGroup.getThreadGroup () to go to the root ThreadGroup (), and then use the iterate () functions to go through all the threads.

Answer 4

Try running jkillthread , which is trying to do something like this.