Hi guys, I’m new to the list.
I did quite a lot of Googling, but didn’t find any specific references
to this topic.
I have a number of simple Java servers which can invoke a series of Java
classes on each other. Each server maintains its own threadpool, and a
given series of classes is executed in parallel using the threadpool’s
invokeAll() method.
I’m extending the server to be able to invoke JRuby scripts as well. So
I need to submit to the threadpool a list containing a potential mix of
Java classes and JRuby scripts.
My question regards the ScriptingContainer.
Can each server maintain just one instance of a ScriptingContainer and
run the various scripts inside? BTW, the scripts themselves never access
any shared JRuby resources, and any access to shared Java resources are
always synchronized in Java.
Are there any performance limitations to this approach (it seems to me
much cleaner just keeping one persistent container instance than
spawning new ones for each JRuby thread). Are there any practical
limitations as to how many scripts can be loaded and executed in a given
container?
If I can use just one container, does JRuby check if the same script is
being loaded more than once into a given container? - the server could
call multiple instances of the same script. In other words, do I have
to maintain a list of loaded scripts and only load a script if it’s not
already in the container, or does runScriptlet() do this for me?
To prevent the server’s memory footprint growing over time, Java classes
are automatically unloaded if they are not called during a certain
period. I was wondering if I could do something similar with a scripting
container, ie selectively unload scripts. Of course I could always
clear() the container, but this would also remove any “hot” scripts as
well.
Thanks in advance for any answers, and apologies if my questions belie a
lack of understanding as to how ScriptingContainers are actually
implemented. I looked quite hard for some implementation descriptions,
but came up empty - of course, I could always look at the source, but
whenever I take that route I generally end up more confused
David S.