Phusion Passenger 4.0 supports JRuby, Rubinius | Hacker News Reader

Phusion Passenger 4.0 supports JRuby, Rubinius

blog.phusion.nl

36 pointsdRiek12 comments

We are in the process of switching a project from Torquebox to Passenger. We spent a lot of time having to fix issues here and there, tweak our chef recipes, and, on top of it, the startup time of JRuby was painful. I'm a huge fan of JRuby and Torquebox, and I hope they do really well. We're a startup, so we need the devops effort to be minimal and the development time to be extremely speedy. I hope we're able to migrate over to JRuby one day in the future after we release.

There are a few reasons we're making the switch, and I'll try and jot down a bunch of them here. I'll also duplicate this information and let the JRuby guys know as well. A little background, I've used JRuby on a few projects, have contributed to the project, some gems, have attended some JRuby conferences, etc. I'm a huge fan of JRuby and its community. That said, here are some reasons we're making the switch:

- Start up time. It starts to sting after a while when frequently firing up console and compiling assets.

- Gems compatibility. For the most part, this is a non-issue, but we had to do some JRuby related patches to some gems (hstore support for postgres, and some others that I can't think of off the top of my head).

- Torquebox. It's a solid project, but we had a bunch of small issues that we can into that made it a bit painful. Weird terminal buffering on console (same thing for ruby-debug), requests dropping on restarts, and some other issues. The baked in backgrounding and the stomplet support is really nice, but we decided to sacrifice these things for something that we understand a lot better (we have a lot more experience with the ruby servers than the JBoss and other java application servers).

A lot of it boils down to us not having the time to learn and fix the issues we were running into w/ the JRuby deployment. We need to focus on building our application, so we don't have the luxury of learning a new deployment ecosystem. That said, we are using AngularJS, so there is "one" thing new that we're all learning.

Interesting, so you are not only switching to Passenger but switching to MRI as well?

I think it might be worth dropping an Email to JRuby mailing list (https://github.com/jruby/jruby/wiki/MailingLists), if you haven't already about what troubles you faced and why you are switching.

really am curious on why you are doing that. Am going to be beginning a new project on jruby.

Really glad to hear this, but IMO, one of the greatest advantages of going JRuby is gaining access to the "Java way". TorqueBox, in particular, is interesting because it includes many of the ad hoc add-ons that Ruby devs source from various locations. There are environments where you really want a single-source stack, rather than pulling from multiple sources.

In principle I agree with what you're saying but Torquebox has been something I've had to constantly work on whereas Passenger has always been, more or less, deploy and forget.

I've been using Torquebox since version 2.0.1 (not that long really) but I've never really had a completely stable server. Deployment has always been somewhat of a hassle and recently the HA cache has been so broken that I have not been able to use torquebox in a cluster.

In the end, I'm just happy to have another option. The more the merrier.

Interesting, but not all that surprising. People are often perplexed by the fact that we continue to stick with Passenger, as opposed to jumping on the bandwagon with the latest and greatest. Passenger is the one piece of my infrastructure that I never have to touch. It also comes with a great toolchain for instrumenting (status and memory usage tools). I've been tempted by TorqueBox in the past, but never made the jump to actually build an app with it.

I agree, one of the main reasons I decided to use TorqueBox was because of this. Requires minimal configuration and I get distributed cache, clustered messaging system, HA scheduled jobs and HA services.

Tomcat deployment is also pretty easy, can package a war file and then there are even context parameters if you want to use the same war for multiple instances. That being said this is a nice option which is already integrated with apache or nginx so don't have to setup a proxy, and this will handle static assets automatically if you are not using a CDN.

Yep. Coming from a different background, Phusion Passenger is not as J2EE-ish as the other Java app servers. We do things a bit differently, for example:

- 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.

- We integrate directly into Apache and Nginx, so no need to setup AJP reverse proxies. I don't think Nginx has an AJP connector.

- 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.

- Our support for multiple Ruby versions (and even multiple languages) allows you to easily mix and match things. No need to commit 100% to Java, or MRI, or any particular implementation/version.

Not sure I agree with their Phusion Passenger vs J2EE. I use torquebox and deploying is just as easy, if not easier. You can instantly deploy an application by executing "torquebox deploy /path/to/your/ruby/app/" or by placing a 2 line .yml file in the JBoss AS deployments folder. Torquebox also comes with Capistrano recipes you can use for automating deployments.

This is also a great news for Rubinius, it will probably boost Rubinius adoption and I'm eager to observe how it behaves compared to MRI.

Reply on news.ycombinator.com