JRuby script engines do not isolate module definitions

Sounds there are exactly the same module names but different behaviors? Would you name those precisely? If you can wrap those by other module names, that should work.

We don't have control over the scripts. They are arbitrary, written by different people who don't know each other.

We tried setting localcontext scope to threadsafe, but then we ran out of memory.

I understood about modules. I don't think there is a way of avoiding module name collision, so, as you (Steven) said, threadsafe model might work. However, running out of memory is tragic. There might be memory leak in threadsafe model. I'll have a look about memory leak.

I attempted to fix memory leak and pushed that in rev. 4f37e5e. The snapshot will be available to get from http://ci.jruby.org/snapshots/

Would you add the last two lines of following code in appropriate position and try your code again using the latest JRuby version.

 
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("jruby");
....
....
engine.getContext().setAttribute("org.jruby.embed.termination", true, ScriptContext.ENGINE_SCOPE);
engine.eval("");

These two lines call the lower layer's terminate method. The terminate method clears saved values up. So, you might avoid memory leak.

If possible, would you give us a sample code that reproduces memory outage. That will be helpful to fix the problem.

This is more a question of Ruby behavior than container behavior. When evaluating code against a container, the code will always run against the same toplevel scope. This means generally that all constants defined will go into Object, and so you could see users stepping on each other.

You may be able to get around this by wrapping user code in a separate module defined on a per-user basis, like this:

container.evaluateWhatever("module " + getModuleNameForUser + "\n" + userCode + "\nend\n)

Does this seem like it would fix the problem for you? As long as the user's code is all running within that module, it should see its own subset of constants. There's of course nothing to prevent a user from reopening Object and adding constants there, but that may be outside the bounds of what you're hoping to support anyway.

Heap dumps are showing a lot of instances of org.jruby.RubyClass being held as ThreadLocal values in org.jruby.embed.internal.LocalContext. How are these supposed to get cleared? Is the threadsafe isolation making it so that these ThreadLocals are not getting cleared?

I think I'll let Yoko answer that...not sure about it myself.

To be clear, those heap dumps are against 1.5.6. We do want to move to 1.6.0.

Would you (Steven) give us your code that reproduces the problem. That will help a lot to fix the bug.

At the moment, that reproduction is the entire running installation of Tropo. I will see what I can do about creating a reproducible test case.

Considerable time since last follow-up, so I'm resolving this as Incomplete. If you are still having issues, please provide a reproduction and reopen.