jetty-rails gem – Simple JRuby On Rails Development with Servlet Containers

This is the first time I’m writing about it, but jetty-rails is already 0.3!

Most people doing JRuby on Rails development are using JMongrels1 for development and some real Java Application Server in production.

The common flow is:

$ jruby script/server 
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at
** Starting Rails with development environment...

code, code, test, code, code, test, … (shouldn’t it be red-green-refactor?)

$ jruby -S warble
$ cp myapp.war $TOMCAT_HOME/webapps

Sure you can automate those things with ant, rake, sake or anything else. Some people are still using the goldspike-plugin, but be warned: I suspect it won’t get much more attention.

The great Warbler from Nick Sieger is becoming the de facto standard for JRuby on Rails packaging. The Warbler’s recent move from goldspike to JRuby-Rack adapter reveals two interesting points:

  1. Goldspike is likely going to be deprecated (or merged with jruby-rack adapter?).
  2. Warbler will soon package any rack compatible application to be runned inside Java Containers. Such applications include Merb, Sinatra, Vintage, Camping ones, and growing

Although Warbler works really well, it introduces complexity in the development cycle. You can no more save code and immediately test it in your browser:

  1. change code;
  2. warble it;
  3. deploy war file;
  4. restart server; (takes long time)
  5. open browser;
  6. change code;

It breaks one of the most important rails development characteristics: instant feedback. During development, it’s very important to see changes without have to wait for server/context restarting.

JMongrel and Glassfish Gem are good candidates for JRuby on Rails development with instant feedback, but you can’t use Java (Servlet specification) specific features, such as web.xml; they aren’t complete Servlet Containers. Some things have an alternative in pure-rails as Servlet Filters and Servlet Listeners, but many haven’t. Servlet Context might be a good way to share things between rails runtimes. I know railers should “share nothing”, but -hey- sometimes it’s so good to share!

You can take the Servlet Application Context as your in-memory cache store (fragment and page caching), eliminating the need for filesystem or database overhead and even memcached, in many cases.

I had also a specific reason to share the same HttpSession between Rails and “pure Java” applications. Single sign-on wasn’t an option, so I needed to run both applications in the same context. I’m going to tell more about it soon.

Anyone can fall in cases, like mine, when you just can’t use jmongrel or glassfish_rails. Now, we fortunately have jetty-rails to rescue!

It’s a (one more) gem to run rails applications, based on the nice JRuby-Rack adapter, which I recommend you to take a look. Jetty is a very powerful Servlet Container, known for being pioneer at being embedded and at using NIO Connectors.

The gem creates a Jetty Server with two Handlers. The first is for static content and the last to serve dynamic requests using JRuby-Rack. These handlers are applied in order and request processing stops when one responds. That way, no rails code is runned to serve static content, improving response times. Take a look at the rdocs for more details.

Jetty is also very quick to start. I’ve measured (in a complete inaccurate way) some start times just for ugly2 comparison:

$ jruby -v
ruby 1.8.6 (2008-03-28 rev 6360) [i386-jruby1.1]
$ time jruby script/server
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on
** INT signal received.

real	0m13.947s
user	0m11.327s
sys	0m0.892s

$ ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
$ time ./script/server 
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on
** INT signal received.

real	0m6.273s
user	0m1.893s
sys	0m0.611s

With the same JRuby 1.1 (and without Charles recent speedup patch for jruby startup):

$ time jruby -S jetty_rails
2008-05-04 10:50:00.846::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
2008-05-04 10:50:01.013::INFO:  jetty-6.1.9
2008-05-04 10:50:02.987::INFO:  Started SelectChannelConnector@

real	0m7.035s
user	0m4.387s
sys	0m0.296s

As you can see, jetty_rails is very close to mongrel running in MRI, but please, don’t take those numbers so seriously.

Jetty Rails should be ready to run any rails application (tell me otherwise!) with no dependencies on extra jars. All gems used by the application must be installed in your JRuby. I’ve made some simple benchmarks with JMeter and only one thread, firing 500 consecutive requests to a simple rails blog application. All requests pointed to ‘/posts’ controller, and there was only one Post is the MySQL database.

The machine used to run all tests is a Intel Core2 Duo E4500 @ 2.20GHz, 2.0GB RAM, running Ubuntu 7.10, Ruby (MRI) 1.8.6 and JRuby 1.1.1. MRI tests were done using plain ruby activerecord-mysql-adapter and JRuby tests were done using activerecord-jdbcmysql-adapter.

Mongrel: 30.7 req/s
JMongrel: 19.1 req/s

Glassfish Gem: 17.5 req/s
dropping JVM warm time: 23.8 req/s

Jetty Rails: 18.2 req/s
dropping JVM warm time: 26.6 req/s

This is obviously a simple measure, just to feel how jetty-rails is going. But I’m very happy with the results. If we ignore the time that JVM takes to warm and JIT compile things, jetty-rails comes close to Mongrel! Impressive. I knew Jetty was always very fast, but I really didn’t expect those results.

There is much more to do. Things from the roadmap I wanted to see working soon include:

  • read warble.rb configuration files and register extra jars and public folders defined there;
  • use any custom web.xml defined in config/web.xml (or config/web.erb.xml), following Wabler conventions.
  • jetty_merb
  • jetty_camping

The source code lives in GitHub. Feel free to fork, contribute, send patches and suggestions!

  1. Can we stop calling everything that comes from Java with that damn J-at-start or with –let termination? 😉
  2. I’ve stopped the processes (ctrl+c) as soon as I saw they were ready to respond to requests.

7 thoughts on “jetty-rails gem – Simple JRuby On Rails Development with Servlet Containers

  1. Excellent. The brevity of the development cycle is very appealing. What do you advise when jetty is already installed and serving other applications (including jruby ones)? Is there a way of obtaining the fruits of the jetty-rails gem without installing further copies of jetty?

  2. Thanks Raphael. Right now, jetty_rails can only use its own embedded jetty, but we could support an external jetty as well. What big advantages do you see?

    Perhaps, it would be good to change the jetty version. We could add this functionality together with support to use an alternative version of jruby-rack.

  3. Your suggestions are great. Developers frequently need to switch versions to conduct tests or to upgrade. Flexibility and control are important. I think developers prefer to be in control of all aspects of the server and other applications like jruby-rack.

    As you have clearly identified, war files are an “end product” that should only be created once everything else is working. In a rails environment, war files don’t always work cleanly. Before a developer can hope to locate a specific rails-war interaction that is the source of a problem, all other bugs must first be ironed out. Jetty-rails promises to be very useful in this regard.

  4. You rocks! Jetty_Rails 0.4 is much faster than glassfish_rails. Thanks for your great work.

    Jetty_Rails segun mi experiencia en mucho mas rapido que glassfish_rails. Gracias por tan estupendo trabajo

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s