Forum: JRuby JMaglev public available

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Fabio K. (Guest)
on 2008-11-22 22:31
(Received via mailing list)
Hi all,
I'm releasing my experiments with JRuby and Terracotta (
http://fabiokung.com/2008/10/08/jruby-sharing-obje...),
so you can play with JMaglev and contribute some code. ;-)

http://github.com/fabiokung/clustered-jruby/tree/master

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:

http://github.com/fabiokung/clustered-jruby/tree/m...

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

1) git clone git://github.com/fabiokung/clustered-jruby.git

2) long time waiting, because terracotta-2.7.1 and jruby-complete are
bundled.

3) cd clustered-jruby

4) mvn install (although 'mvn package' is enough)

5) cd jmaglev

6) start the terracotta server:
    lib/terracotta-2.7.1/bin/start-tc-server.sh

7) open another two terminals

8) run the simplified jirb inside them:
    cd clustered-jruby/jmaglev
    ./bin/jmaglev jmaglev.rb

9) follow the demo. You will be able to share global variables among all
jmaglevs:
    require 'hat'
    $hat
    require 'rabbit'
    $hat.put(Rabbit.new)

10) 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.
http://www.fabiokung.com

Caelum - Ensino e Inovação
http://www.caelum.com.br
Charles Oliver N. (Guest)
on 2008-11-23 07:12
(Received via mailing list)
This is great, Fabio, thank you for releasing this. Are you going to
post another blog entry showing how others can try this out?

Fabio K. wrote:
> patch against the current jruby trunk (rev. 8091) and the patched
> REQUIREMENTS: git, mvn and jdk 1.5
> 5) cd jmaglev
> 9) follow the demo. You will be able to share global variables among all
> almost every time (per JVM). Unfortunately I haven't much time (and
> now. Perhaps, with the new thread-safe Rails, multiple runtimes inside
> classloader. As I'm always using the same classloader, I'm also using
>
> I hope to see many contributions. Happy hacking!
>
> Cheers,
> --
> Fabio K.
> http://www.fabiokung.com
>
> Caelum - Ensino e Inovação
> http://www.caelum.com.br


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Fabio K. (Guest)
on 2008-11-23 07:27
(Received via mailing list)
Yes, I've already posted on my blog:
http://fabiokung.com/2008/11/22/play-with-jmaglev-yourself/

Thanks!

On Sun, Nov 23, 2008 at 3:12 AM, Charles Oliver N. <
removed_email_address@domain.invalid> wrote:

>> so you can play with JMaglev and contribute some code. ;-)
>>
>> 2) long time waiting, because terracotta-2.7.1 and jruby-complete are
>>
>>    require 'rabbit'
>> always retrieve the current Runtime from the classloader that loaded the
>> Another thing you may discover (and I know), is that code for this part is
>> pass Runtimes as method parameters, whenever needed.
>> Fabio K.
>   http://xircles.codehaus.org/manage_email
>
>
>


--
Fabio K.
http://www.fabiokung.com

Caelum - Ensino e Inovação
http://www.caelum.com.br
Charles Oliver N. (Guest)
on 2008-11-23 07:38
(Received via mailing list)
Oh, nevermind, I just saw your post from today :)

Charles Oliver N. wrote:
>> http://github.com/fabiokung/clustered-jruby/tree/master
>> a sample maven project and the JMaglev use-case included.
>> bundled.
>> 7) open another two terminals
>>     $hat.put(Rabbit.new)
>> the class. I would have to use a different classloader for each JRuby
>> part is ugly. Here are some places to look:
>> pass Runtimes as method parameters, whenever needed.
>> Fabio K.
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
This topic is locked and can not be replied to.