Our team was initially very attracted to the deployment simplification promises of Torquebox and the enterprise integration capabilities of being on JRuby. However, after struggling to create performant and understandable production and staging environments, our team has regretfully decided to back away for now--we’re not Java dudes, and there is too much complexity that we don’t know how to deal with efficiently as Rails developers with no Java background.
For our product launch, we’re going back to Apache/MRI/Passenger--thats the only way we’ll feel comfortable maintaining and troubleshooting the system when it inevitably goes bump in response to new user interactions and under load. We wish it weren’t the case, but without significant investment in learning how JBoss, JRuby, JDBC, and Torquebox really work under the hood, we simply can’t justify the risk of running a Rails infrastructure we don’t understand.We still think that Torquebox and JRuby is one of the most compelling Rails deployment options out there, but right now, in our opinion, its not ready unless you’ve got the stomach to get down with Java. In light of this, we’re going to maintain MRI and JRuby compatibility for at least the next year to be prepared to switch to Torquebox/JRuby when the time is right, when either we have cultivated the needed Java knowledge on our team or Torquebox is a little easier to use for non-Java people. We’d love to use Torquebox/JRuby and are thoroughly bummed that its not feasible to do so now for us. Talk to us in year.
Joe Goggins, Chris Dinger: Academic Support Resources Web-Team, University of Minnesota
