6

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.)

Community
  • 1
  • 1
greghmerrill
  • 695
  • 7
  • 13

1 Answers1

4

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.

AlexR
  • 114,158
  • 16
  • 130
  • 208
  • I'm not actually not disputing whether or not Thread.stop() will really stop the thread - it definitely will. The question is whether it is too *risky* to stop the thread due to the potential of leaving various objects in a bad state. In general though I think I agree with you that this is probably one case where the benefits outweight the risks. – greghmerrill Aug 29 '11 at 21:03
  • 1
    @greghmerrill *Thread.stop() will really stop the thread - it definitely will.*, not necessarily threads waiting on a monitor may not be stopped (i.e. you have to kill the thread the holds the lock 1st). `Thread.stop()` is *almost* ok in case you know if you can use it, examine the stack trace and mark some dangerous moments. Alternatively use a code enhancer that peppers the code and checks `Thread.interrupt()` or calls any other static *safe point* to throw an error similar to ThreadDeath. – bestsss Aug 30 '11 at 06:08
  • @bestsss _not necessarily threads waiting on a monitor may not be stopped (i.e. you have to kill the thread the holds the lock 1st)_ - this was news to me, thanks for the tip! I [tried it out](https://gist.github.com/1183567) and you are definitely right, stopping a Thread which is acquiring a lock will _not_ immediately stop that thread, although it will stop as soon as the lock is acquired. – greghmerrill Aug 31 '11 at 13:49
  • Going with this response as that's how I intend to proceed, i.e. by using Thread.stop() with judicious comments & caveats. – greghmerrill Aug 31 '11 at 13:50
  • @greghmerrill, you're welcome. What i usually do is stopping entire ThreadGroups (not by ThreadGroup.stop(), though). There are dangerous areas that if the stack trace shows about you should skip and re-try stop after a few nanos. (for instance `java.util.concurrent.locks`). Other option would be to change groovy itself to add some code that often checks Thread.interrupt(), it should be a relatively easy to implement. Note 2: stopping (throwing ThreadDeath) occurs at HotSpot safe points and it's virtually impossible to know where a SP will be placed. – bestsss Aug 31 '11 at 15:31