On Nov 19, 3:11 pm, SCWells72 <[EMAIL PROTECTED]> wrote: > We're looking to integrate Java 6's embedded version of Rhino for > extensibility, but one thing that worries us is the possibility of > someone writing a script that goes rogue in some fashion and tanks at > least that thread if not the entire server instance (especially if > multiple requests cause that script to go rogue on multiple threads). > We do this in Acre so that we can put a time limit on how long a script can run. We also have a patch to the JVM to let us control memory usage as well (which is a problem you'll probably need to consider).
Rhino provides a way to be notified when a certain instruction count threshold has been reached and you can react on that. What we do is we throw an exception that can't be caught when the time limit is reached.You'll want to subclass ContextFactory and call setInstrutionObserverThreshold,and then implement an observerInstructionCount method. What we do is note the initial time on execution, and then check if the time difference between the initial time and the current time has exceed our limit, and if it has we. throw an exception. > We'd like to be able to set a timeout on the execution of a script > after which we'd terminate the script's execution and report an error > to the user. > > To further complicate things, we also want to use the ability to > compile into bytecode for optimal execution speed. If we were > evaluating a script, I think terminating the interpreter would be a no- > brainer. However, once the script is compiled into and executed as > bytecode, I'm concerned that you're looking violating the old "never > call Thread.stop()" rule to get a rogue execution thread to terminate. > We run in compiled mode, the trick is the exception is used. Alex _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
