Phusion white papers Phusion overview

Phusion Blog

Phusion Passenger 4.0 supports JRuby, Rubinius

By Hongli Lai on October 30th, 2012



Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python web applications. It has a strong focus on ease of use, stability and performance. Phusion Passenger is built on top of tried-and-true, battle-hardened Unix technologies, yet at the same time introduces innovations not found in most traditional Unix servers. Since mid-2012, it aims to be the ultimate polyglot application server.

In the announcement for Phusion Passenger 4.0.0 beta 1, we introduced a myriad of changes such as support for multiple Ruby versions, Python WSGI support, multithreading (Enterprise only), improved zero-copy architecture, better error diagnostics and more. And as we promised, the story would not end there. A commit has just landed in our Github repository for JRuby (1.7.0 required) and Rubinius support!

JRuby: the past and the current state of affairs

JRuby is an excellent Ruby implementation for the JVM, and in the past few years they have been doing a great job with regard to compatibility and performance. But for a long time, application server support for JRuby had been limited:

  • While Mongrel and Thin had limited JRuby support, these setups have not been very popular. Since so few people use these setups, their caveats are not very well known.
  • Unicorn does not support JRuby at all because it was designed to take advantage of Unix features, which JRuby does not (and cannot) always support well.
  • Phusion Passenger was in the same position: we used too many Unix features and were not able to support JRuby well.
  • Goliath does not seem to have official support for JRuby thanks to the unknown status of EventMachine’s Java support.

So the only options left were J2EE app servers such as JBoss, Tomcat, GlassFish and TorqueBox; as well as the recently developed Puma, which is almost pure Ruby.

Thanks to the new ApplicationPool and Spawner architecture in Phusion Passenger 4, we’re now able to support JRuby with ease. Because a lot of code has been moved into C++, we no longer need the Ruby implementation to support Unix features. We only needed an hour to add support for JRuby.

Phusion Passenger vs J2EE

With Phusion Passenger’s support for JRuby, you don’t need to learn about J2EE deployment. Using JRuby on Phusion Passenger is very straightforward: set PassengerRuby to your JRuby command, point the virtual host’s document root to your application’s ‘public’ directory, and you’re done.

With Phusion Passenger Enterprise, JRuby users get to enjoy all the enterprise features such as multithreading, rolling restarts, deployment error resistance, time and memory usage limiting, and more.

Rubinius is impressive as well

We remember that back in the days, Rubinius was quite slow during startup and did not support MRI native extensions. Fast forward to 2012, and what we find is a very impressive Ruby implementation. They have 1.9 support and MRI extension support. The Ruby interpreter starts quickly. They support Unix features. Adding Rubinius support was pretty straightforward. The Rubinius team has done an excellent job!

Why you should use JRuby or Rubinius

JRuby and Rubinius support real multi-core concurrency. JRuby and Rubinius threads map to real OS threads, and neither Ruby implementations have a global interpreter lock. In contrast, MRI Ruby 1.8 uses userspace threading and so cannot take advantage of multi-core using a single process. MRI Ruby 1.9 has real OS threads, but also has a global interpreter lock and so still cannot take advantage of multi-core using a single process.

Granted, the multi-core issue isn’t that big. Phusion Passenger spawns multiple processes in order to take advantage of multi-core. But if you’re in a position in which you can only use 1 process, for whatever reason, then JRuby and Rubinius are what you need. With Phusion Passenger Enterprise’s multithreading support, you can have hybrid multi-processed and multi-threaded applications – the best of both worlds.

JRuby and Rubinius also often have superior performance. Both implementations support JIT compilation, which MRI Ruby does not.

That said, MRI Ruby still has the best compatibility in the Ruby ecosystem, so JRuby and Rubinius are not silver bullets. You should use the best tool for the best job. With Phusion Passenger 4’s support for multiple Ruby versions, this should be a breeze.

Where to get Phusion Passenger with JRuby/Rubinius support

JRuby/Rubinius support will become part of the upcoming 4.0.0 beta 2. Please stay tuned!

These Phusion Passenger 4 updates are just the beginning. We have more exciting changes planned for the near future! Curious? Enter your email address and name below and we’ll keep you up to date.

  • adrianoconnor

    Great news, though to be fair, Tomcat has always been a very good option for JRuby and I’m not sure why you wouldn’t use that. I think I think I’d still recommend Tomcat for JRuby deployments, serving static content from your Nginx/Apache server, and passing any non-matching URLs through the AJP connector. It’s very easy to setup, very easy to manage, and very fast. I still love and use passenger for my MRI 1.9.3 sites though, which is nearly all of them 🙂

  • You could use Tomcat, but our strength lies elsewhere (and correct me if I’m wrong because it’s been a while since I’ve used J2EE):

    – We integrate directly into Apache and Nginx, so no need to “pass any non-matching URLs through the AJP connector”.

    – I don’t think Nginx has an AJP connector.
    – We don’t run multiple apps inside the same JVM. We strictly run each app in its own JVM, no exceptions. As I’ve understood, running multiple apps in the same JVM can cause garbage to leave behind when you try to uninstall an app. And the JVM does not always perform optimally when the heap is large.
    – Phusion Passenger is also a great option for people who want to take advantage of JRuby (whether it’s for the speed, or the threading implementation, or whatever) but aren’t intimately familiar with the J2EE stack.

  • Rob

    Great news! Good work, guys. 🙂 JRuby support sounds like a great achievement in terms of engineering effort.

  • hipertracker

    Torquebox has more features than Tomcat, it has out of box: load balancer, cluster, caching, scheduled jobs, long running processes, asynchronous messages, web sockets etc.

  • pawelpacana

    Great news indeed! However when mentioning “only options” you completely missed Mongrel2 existence which thanks to m2r works with any Ruby implementation and programming model you want on backend.

  • Awesome news! We hope to make use of JRuby and the ability to have interoperability with java for Right now we use pure Ruby, but going further, we see a lot we could benefit from by using JRuby.

    Keep up the excellent work!

  • adrianoconnor

    You are right, you certainly do have other strengths and I don’t mean to downplay the brilliance of passenger at all, or the fact that this is another great option for hosting JRuby web apps. I will certainly try it out very soon.

    I think the biggest advantage I see in Tomcat’s favour is that I can install Apache, Java and Tomcat very quickly and without needing any development tools or headers on the production server. Configuring the AJP proxy and re-write rules is another step, but it’s pretty easy to do.

    It might also be true what you say about accumulated garbage, though I haven’t seen that on our servers. It’s very easy to run separate Tomcat instances on different port numbers, and that’s what we do.

  • Chris

    So is it possible to run Passenger 4 with some Ruby-1.8.7, Ruby-1.9.3 and Jruby apps? all running together at the same time?

    “Phusion Passenger is very straightforward: set PassengerRuby to your JRuby command”

    This is a global command right? If so, how does this support using different versions of ruby at the same time?

  • So is it possible to run Passenger 4 with some Ruby-1.8.7, Ruby-1.9.3 and Jruby apps? all running together at the same time?


    This is a global command right?

    It was. Not anymore since 4.0 beta 1:

  • Pingback: This Week in Ruby: Rubinius 2.0-rc1, Rake 10, Refactoring video, Passenger 4.0 supports JRuby, and more()

  • Pingback: What’s New in Ruby: November 2012 edition « databasically // Kansas City Small Business IT && Ruby on Rails Programming()

  • I am definitely interested in beginning to use the open source version of the 4.0.0 beta 2 release with JRuby as soon as possible. I am a bit unclear abut how to get this working, however. When I dowload the tarball and attempt to install, I get some C extension errors because of JRuby’s limited support for gems with C extensions. Should I install Passenger with vanilla ruby 1.9.3 and the passenger-install-apache2-module install script, and then change the PassengerRuby setting after the installation? A bit confused.

  • The build system has not been tested with JRuby, so the recommended way would be to install with MRI, then change the PassengerRuby directive. I’ll get this fixed so that you can compile with JRuby.

  • Pingback: Books about developing » Blog Archive » This Week in Ruby: Rubinius 2.0-rc1, Rake 10, Refactoring video, Passenger 4.0 supports JRuby, and more()