Ruby/JRuby Process Models Explained

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

• Traditional C-based Ruby on
  Mongrel,
• JRuby on Mongrel, and
• JRuby on
  GlassFish.

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