Miles to go ...

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

Posted by Arun Gupta in web2.0  |  Comments[0]