

Phusion Passenger 4.0 supports JRuby, Rubinius - dRiek
http://blog.phusion.nl/2012/10/30/phusion-passenger-4-0-supports-jruby-rubinius/

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

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

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

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

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

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

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

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

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

