Question

I’d like to add groovy-shell-server to our application. We have run into a couple production issues recently where a call to an internal API could have expedited diagnosis or even provided a short-term fix. Groovy-shell-server provides a nice way to achieve this.

But actually using this in production introduces a potential complication. Let’s say that, despite careful peer review, we execute a script which pegs the CPU, or gets stuck in an endless loop. I need some way to kill that thread, pronto! So I was thinking about enhancing groovy-shell-server to support an optional hard stop() of a running Groovy client thread.

I know that Thread.stop() is inherently unsafe; it’s been discussed on StackOverflow before. My question is, do you think the benefits might outweigh the risks in this case? Is using Thread.stop() a pragmatic choice as a kind of “emergency brake” for a runaway GroovyShell server thread? Or the likelihood of leaving objects in an inconsistent state is too high?

(Alternately, if someone has a better way to provide programmatic, interruptible access to a running java application, I’m all ears.)

Answer 1

I think that generally is it bad to use deprecated API and specifically it is not recommended to use Thread.stop().

BUT there is not rule without exception. I think this is the case. According to my experience Thread.stop() works and really stops thread. I used it many years ago in applet that was targeted for Netscape. Some of its versions did not support Thread.interrupt() well.

The only alternative solution I can think about is using separate process. But in this case you have to implement some process-to-process transport for data transfer. I do not know details of your task but usually the price is too high.

So, if I were you I’d use Thread.stop() with very big apologize comment.