Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news.

Torquebox: An All-In-One Java/JBoss Powered Ruby Webapp Platform

By grantmichaels / November 11, 2009

torquebox2In the past two years we've seen a number of changes in the world of Ruby webapp deployment, but have you heard of Torquebox? Built upon the Red Hat Inc. JBoss middleware, Torquebox is an enterprise-grade application server that provides scale-oriented services to your Ruby webapps, including turn-key clustering. With its latest release, Torquebox supports all Rack-based Ruby frameworks.

Torquebox comes with job scheduling and asynchronous task scheduling out of the box (no extra installs necessary), and while I've grown fond of RabbitMQ, the ease of using the built-in JMS (Java Message Service) messaging is appealing, particularly if you're likely to deploy within a Java dominant environment. If you are having trouble convincing management to let you use Ruby, Torquebox is the most enterprise-oriented platform I've seen to date. Not just that, it's open-source and licensed under the LGPLv3. Their community site boasts that JBoss (upon which Torquebox is built) is "the world's number one Java application server, and it was created by the community."

Torquebox 1.0.0.Beta18 was released within a day's time from the latest JRuby 1.4 release and you can download Torquebox from its download page, or build it yourself from source easily obtained from GitHub. If you are using Mac OS X, the following code sample will get you up and running with a simple cut and paste:

mv torquebox-1.0.0.Beta18-bin torquebox
export TORQUEBOX_HOME=~/torquebox
sudo gem install jruby-openssl
sudo gem install activerecord-jdbcsqlite3-adapter
cd ~/torquebox/share/rails
rails -m template.rb ~/torquebox_rails_app
cd ~/torquebox_rails_app
rake rails:freeze:gems
emacs config/database.yml

# (now prefix sqlite3 with jdbc to become "jdbcsqlite3")

jruby -S rake gems:install
jruby -S rake db:migrate
jruby -S rake torquebox:rails:deploy
jruby -S rake torquebox:server:run

While waiting for JBoss to unfurl, you can close your eyes and do a mental walk-through of installing Erlang, a RabbitMQ daemon, cron, HAProxy, etc. – because you won't have to do that with Torquebox – and when you open your eyes approximately two minutes later, you should be able to see the default Rails page at http://localhost:8080. While everything appears the same as if you were running on it on a Mongrel, you're really experiencing Rails as it's presented from within a JBoss AS appserver, more about that in a minute.

Handily, Torquebox contains tried-and-true JDBC drivers for a number of databases, including Derby, H2, HSQLDB, MySQL, PostgreSQL, and of course, SQLite3. Additionally, Torquebox is Capistrano friendly – so you probably won't need to learn any new tricks to deploy – and it also has built-in support for cryptographic key-storage.

With an application appropriately bundled into a WAR file, you can utilize Torquebox's farming to "deploy your app to one node of the cluster, and to have that node farm it out to all of its peers." Torquebox uses httpd+mod_cluster out in front, so it's "intelligently aware" of your JBoss cluster, and thus, if you have a two-node cluster running, and you start two more JBoss instances on the same subdomain, they'll auto-join the cluster and then the existing nodes will auto-farm the app to them. You're app now has twice the resources and didn't need to be restarted, which in and of itself, is pretty huge.

So, where does Torquebox fit in? One can make the argument that it fits "everywhere." The JVM comes pre-installed on Macs, is easy enough to add to Linux or a Windows desktop, and of course deploys to a number of hosts. Scaling the JVM isn't new, and finding the people to do so is probably easier than finding dedicated Ruby programmers. I would be remiss not to point out that JBoss is hungry for RAM, and I realized quickly that Torquebox wanted more cowbell than my Linode 720 could afford. Engine Yard Cloud greatly simplifies deployment to EC2 instances (via Chef), and the smallest instance provides a whopping 1.7GB RAM, so scaling JRuby through the company that houses the JRuby core commiters just makes sense to me. If, however, you feel better qualified to deploy Torquebox yourself, you might look at JBoss Cloud.

I recommend taking 10 minutes to watch the pair (1, 2) of screencasts by Bob McWhirter, which demonstrate all of what I've highlighted here in well under a half an hour.

caliper-logo.png[ad] Find duplication, code smells, complex code and more in your Ruby code with Caliper! The metrics are free and setup takes just one click. Get started!


  1. JB says:

    I was definitely interested in Torquebox when it came out...but since that time have heard no examples of real world usage. It'd be really useful for the devs to point out any projects currently using it (if there are any)...

  2. Martijn says:

    Interesting.. I'm quite happy with our current Glassfish deployments, but something more community-based is always good. I've messed around with Geromino in the past but never got it to work properly.

  3. paulbonner says:

    I deployed a Rails-based contract-management application to production on Torquebox several months ago, and at this point am planning on using it for all JRuby deployments. We're primarily an enterprise Java shop, and all our Java runs on JBoss, so Torguebox makes it considerably easier to fit JRuby development into our existing infrastructure and support matrix. So far, we're more than pleased with the performance and stability of the Torquebox platform -- although as the author notes it is considerably more hungry for memory than a Mongrel cluster. Some of the built-in extras are quite nice (we're using the scheduler, and have begun to use JBoss Cache as a poor-man's Memcache), but for us the primary appeal is the ability to better integrate our JRuby development into our Java infrastructure.

  4. Martin says:

    doesn't work for me. I got:

    NativeException in Rails/infoController#properties

    java.lang.RuntimeException: Failed to read zip file: - /Users/martin/torquebox_rails_app/vendor/rails

    RAILS_ROOT: /Users/martin/torquebox_rails_app

    Application Trace | Framework Trace | Full Trace
    org/jboss/virtual/plugins/context/zip/ `ensureEntries'
    org/jboss/virtual/plugins/context/zip/ `checkIfModified'
    org/jboss/virtual/plugins/context/zip/ `getChild'
    org/jboss/virtual/plugins/context/zip/ `createChildHandler'
    org/jboss/virtual/plugins/context/ `structuredFindChild'
    org/jboss/virtual/plugins/context/zip/ `getChild'
    org/jboss/virtual/ `getChild'

    does anybody know a solution for this?

  5. Bob McWhirter says:


    If you could send a fuller stack-trace (including any Ruby portion) along with more environment/deployment information to the list, I'm sure we could track this down.

    The VFS/VirtualFile bits are definitely new and quite possibly a little brittle.

  6. Tex says:


    I had the same problem but with jrails plugin.

    I've solved renaming vendor/plugins/jrails in vendor/plugins/rails-jquery (maybe jboss finding a folder named j* thinks that folder is a "zip" entry...)

    Now all are working good (I'm very satisfied with torquebox !!!)

    Hope this helps...

  7. Tex says:


    there is no reason to have rails under vendor/rails if you use rails v. 2.3.4 (torquebox already use the last rails version) so if you use 2.3.4 version try removing vendor/rails...

Other Posts to Enjoy

Twitter Mentions