Skip to main content

Ruby/JRuby Process Models Explained

Posted by arungupta on August 20, 2007 at 9:31 AM PDT

In the
JRuby Hackday
, Nick Sieger
described the process models of a Rails application deployed using

In this blog entry I'm capturing a brain dump from him after the event. The images below shows
process models in each of the above mentioned approaches. The containment of boxes in each image is shown in terms of the application
logic instead of the process. The legend followed in the images is as follows:

In the first approach, a C-based Ruby on Rails application is
front-ended by an HTTP library - Mongrel. The typical app will be
deployed on a cluster of Mongrel servers - provided by

Mongrel_cluster plug-in
.

This plug-in configure and control the several Mongrel servers.
Mongrel is largely written in Ruby and uses native C for HTTP request
parsing. Each instance of Mongrel starts a Ruby interpreter that listens
on a server socket. The Ruby script has a Mongrel handler that queues up
multiple requests from the client and passes the state, one at a time,
to a Rails instance (that is by design single threaded).

For a Mongrel cluster, multiple Ruby interpreters are started as an OS
process.

The second approach shows how a Rails
application may be deployed using JRuby. This is a transition approach
between traditional C-based Ruby on Mongrel deployment and JRuby-based
deployment on GlassFish.


Mongrel JCluster
is an update to Mongrel_cluster that only runs in
JRuby. The biggest difference is that it starts only one Java Virtual
Machine (JVM) that starts several Mongrels in the same JVM by spawning
multiple JRuby processes, one in each thread. As in traditional
approach, each Mongrel listens to the request on a server socket and
passes the request state to Rails.

For a Mongrel JCluster, only one JVM
is started as an OS process.

The last approach shows how a JRuby application may be deployed on
GlassFish. With this approach,
there are two modes to deploy an application.

In the first case,

Goldspike plug-in
is installed in a standard Rails application. This
plug-in adds the "war:*" rake targets to a
Rails
project. Invoking "war:standalone:create" rake target
creates a WAR file containing all the dependent JRuby and Rails libraries. This WAR file
can then be deployed in GlassFish. The "web.xml" in this WAR file contains
a Servlet (org.jruby.webapp.RailsServlet) that translates data from
Servlet request to Rails dispatcher.
In the second case, the
Grizzly
connector
understands the request format and dispatch it directly to a
pre-configured JRuby installation (updated with the Rails gem). In both
the cases, there is only one JVM running as the OS process for GlassFish.
The main advantage of the second approach is that it by-passes the web application
processing and delegate the request directly to the Rails framework.

A detailed screencast of
the first GlassFish case (Goldspike/JRuby) is available

here
and for the second case (Grizzly/JRuby) is documented

here
.

Technorati:
ruby
jruby
jrubyonglassfish
glassfish
grizzly
goldspike
rubyonrails
ror

Related Topics >>