Hi all,
I’m releasing my experiments with JRuby and Terracotta (
JRuby, sharing objects across multiple runtimes. JMagLev? | Fabio Kung),
so you can play with JMaglev and contribute some code.
I had to patch JRuby to make RubyObjects a little less dependent from
the
current JRuby Runtime. It isn’t perfect yet, but is working. The patch
against the current jruby trunk (rev. 8091) and the patched
jruby-complete
are included in the project:
The github project is just a TIM (Terracotta Integration Module) with a
sample maven project and the JMaglev use-case included. Unfortunately, I
haven’t any time yet to upload the TIM to Terracotta Forge.
For those who want to reproduce my JMaglev demo, here is a step-by-step:
REQUIREMENTS: git, mvn and jdk 1.5
-
git clone git://github.com/fabiokung/clustered-jruby.git
-
long time waiting, because terracotta-2.7.1 and jruby-complete are
bundled. -
cd clustered-jruby
-
mvn install (although ‘mvn package’ is enough)
-
cd jmaglev
-
start the terracotta server:
lib/terracotta-2.7.1/bin/start-tc-server.sh -
open another two terminals
-
run the simplified jirb inside them:
cd clustered-jruby/jmaglev
./bin/jmaglev jmaglev.rb -
follow the demo. You will be able to share global variables among all
jmaglevs:
require ‘hat’
$hat
require ‘rabbit’
$hat.put(Rabbit.new) -
in the other terminal, try to see the “magic hat” contents:
$hat
Now the hard part. My patch forces JRuby to use the same Runtime
almost every time (per JVM). Unfortunately I haven’t much time (and
competency) yet to spend on this.
One idea (from Charles) to support many runtimes for each JVM, is to
always
retrieve the current Runtime from the classloader that loaded the class.
I
would have to use a different classloader for each JRuby Runtime
instance,
and probably it would require shared jruby objects to be serialized
between
different runtimes, in the same JVM! (argh, are you also thinking in
local-EJB calls?).
I’m taking the easy path and just supporting one-runtime-per-jvm by
now. Perhaps, with the new thread-safe Rails, multiple runtimes inside
one
JVM are becoming less needed. Does anyone know other useful cases for
multiple runtimes per JVM?
Another thing you may discover (and I know), is that code for this part
is
ugly. Here are some places to look:
org.jruby.Ruby#Ruby
org.jruby.Ruby#getCurrentRuntime
I’m keeping the last created Ruby Runtime inside the current
classloader. As
I’m always using the same classloader, I’m also using the same Runtime.
This
is the same as a static field somewhere and you can help me here.
Another way is to make a huge change to JRuby architecture, and always
pass
Runtimes as method parameters, whenever needed.
What do you think? Any other ideas?
I haven’t tested it with rails applications, but right now, it isn’t
able to
run IRB. I never thought that running IRB could be so hard.
I hope to see many contributions. Happy hacking!
Cheers,
Fabio K.
Caelum - Ensino e Inovação
http://www.caelum.com.br