Ruote & JRuby

[Nathan]

Is anyone running ruote in production using JRuby? As ruote uses
threads, I was thinking JRuby might be a more natural env. for it than
MRI.

Thanks,

Nathan

[John Mettraux]

Hello Nathan,

I'm not using JRuby in production for ruote (I used to back in 2007, but since then the whole product got sold to another company, I was using JRuby to infiltrate Java, not for performance reasons), but here is a summary of how ruote uses threads:

- the ruote worker has its own thread, it's a loop that goes "fetch schedules, trigger the ones that are due, fetch msgs, trigger them, sleep a bit".

- the dispatcher, upon receiving dispatch orders from participant expressions (via the worker), will do the participant worker in a new thread (unless the engine or the participant says it does not want a new thread). Without a new thread, the participant [dispatch] work happens in the worker's thread (thus blocking other workflows (unless there are multiple workers)).

I'd say JRuby might shine when there are lots of "dispatches". IIRC the recent versions of JRuby got rid of the GIL.

Best regards,

--
John Mettraux - http://lambda.io/processi

[Nando Sola]

Hello Nathan,

We are using Ruote and JRuby in a couple of projects. One of them is
in production right now.

The first one, uses ruote-kit as the process API, so we wrap it with
Trinidad[1] (an embedded Tomcat server, with NIO support, lifecycle
extensions and easy daemonization)

The second one, uses AMQP as an async API to interact with processes,
so no ruote-kit is really needed, although it's a good way to
visualize and manage our ruote environment, so we pretty much took the
approach I've just mentioned above. It might be interesting to mention
that, for performance reasons, we use the Java-AMQP driver instead of
the Ruby one.

As for the JVM side, just use (Open)JDK7 in order to benefit from the
huge speed improvements InvokeDynamic offers. Moreover, you should put
extra care on tuning your JVM and garbage collector properly[2]: it
really makes a difference.

The bloodiest side of the "JRuby way" is integrating with Java
libraries, which we accomplish via JRuby's Maven/Bundler
integration[3]. It works for us.

If you want to know something more, feel free to ask us.

Regards,
//nando


[1] https://github.com/trinidad/trinidad

[2] http://java.sun.com/performance/reference/whitepapers/tuning.html
http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html
http://java.sun.com/performance/jvmstat/visualgc.html

[3] http://blog.mkristian.tk/ (lots of info about jruby-maven-plugin)
https://github.com/torquebox/jruby-maven-plugins

[Nando Sola]

On 13 Nov, 23:05, John Mettraux <jmettr...@gmail.com> wrote:
[...]

>
> I'd say JRuby might shine when there are lots of "dispatches". IIRC the recent versions of JRuby got rid of the GIL.
>

That is correct, at least for all the "modern" versions from JRuby 1.5

Here's a good thread about the different rubies and their threading
capabilities:
http://www.ruby-forum.com/topic/216913

Regards,
//nando

[Nathan Stults]

Thank you both for the insight. I will definitely move our workflow
server to JRuby + JDK7.

Thanks,

Nathan

Regards,
//nando

--
you received this message because you are subscribed to the "ruote
users" group.
to post : send email to openwfe...@googlegroups.com to unsubscribe
: send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en