Thread.strop removed: how to deal with a rogue ScriptEngine thread?

[Roger Riggs]

Hi Francois,

[The core-libs-dev at openjdk.java.net would also be a good mail list for 
the discussion.]

There is no simple solution to stopping runaway computations and 
retaining the integrity
of the remaining system but there are mitigations that can incrementally 
reduce the impact.

If you control the scripting language that is exposed, you can build in 
checkpoints
for runaway cpu consumption. Lightweight checks such as elapsed clock 
time (System.nanoTime)
can be used to periodically check for accumulated cpu time, and other 
resource excessive usage.

Impact on other processes can be reduced by throttling the computation 
by introducing
wait times to avoid exceeding some threshold of the ratio between 
cputime and clock time.
Depending on what's in the loop, throwing InterruptedException may 
sufficiently disrupt
the loop so it terminates.
If the script is really while(true){}; then perhaps the interpreter can 
flag that as a potential bug.

Regards, Roger


On 7/23/18 8:55 AM, Francois wrote:
> Hello,
>
> I'm not sure at all it is the correct mailing list for that, so sorry 
> if it is not, and please let me know where I should post my concerns.
>
> So, in JDK 11, the long term deprecated Thread.stop() will is removed 
> (https://bugs.openjdk.java.net/browse/JDK-8204243), and I have an use 
> case that I don't know how to deal with afterwards.
>
> We use nashorm to provides user with a embeded scripting languageon 
> our plateform. Only simple things are accessible, and we try to forbid 
> dangerous things like killing the host process, deleting the 
> underlying filesystem, or infinite, not 
> pause-to-look-for-Thread.interrupt while loops.
> The first two kind of problem are easely managed with a custom 
> security manager and a thread factory that uses itfor starting the 
> sandboxed process (ie: nashorn.eval).
>
> But I don't know how to manage the while(true){} loop. In that case, 
> the nashorn thread does not respond to Thread.interrupt (it is a wide 
> source of surpise and wonders on the internet, see for example: 
> https://stackoverflow.com/questions/1601246/java-scripting-api-how-to-stop-the-evaluation/1601465#1601465 
> and the problem is more generally that Java ScriptEngine API does not 
> provide a way to interrupt underlying process ounce started). So I 
> used to have a timeout counter and a Thread.stop() on it. Ido 
> understand that it could still raise problems, even with the custom 
> threadfactory and the very specific use case, but it was the only 
> solution I knew of at hand.
>
> But now, I don't have any at all to prevent an user to start 
> unstoppable thread (by malice or by error).
>
> Any help would be much appreciated on that topic.
>