Friday, September 14, 2007

The End Is Near For Mongrel

At conferences and online, Tom and I have long been talking about a mystery deployment option coming soon from the GlassFish team. It would combine the agile command-line-friendly model of Mongrel with the power and simplicity of deploying to a Java application server. We have shown a few quick demos, but they have only been very simple and very limited. Plus there was no public release we could give people.

Until Now.

Today, you can finally download the GlassFish-Rails preview release gem.

So what is this tasty little morsel? Well, it's a 2.9MB Ruby gem containing the GlassFish server and the Grizzly connector for JRuby on Rails. It installs a "glassfish_rails" script in JRuby's bin directory, and you're done.

Witness!

~ $ gem install glassfish-gem-10.0-SNAPSHOT.gem
Successfully installed GlassFish, version 10.0.0
~ $ glassfish_rails testapp
Sep 14, 2007 3:00:45 PM com.sun.enterprise.v3.services.impl.GrizzlyAdapter postConstruct
INFO: Listening on port 8080
Sep 14, 2007 3:00:46 PM com.sun.enterprise.v3.services.impl.DeploymentService postConstruct
INFO: Supported containers : phobos,php,web,jruby
Sep 14, 2007 3:00:46 PM com.sun.grizzly.standalone.StaticResourcesAdapter <init>
INFO: New Servicing page from: /Users/headius/testapp/public
/Users/headius/NetBeansProjects/jruby/lib/ruby/gems/1.8/gems/actionmailer-1.3.3/lib/action_mailer.rb:50 warning: already initialized constant MAX_LINE_LEN
Sep 14, 2007 3:00:53 PM com.sun.enterprise.v3.server.AppServerStartup run
INFO: Glassfish v3 started in 9233 ms

That's all there is to it...you've got a production-ready server. Oh, did I mention you only have to run one instance? No more managing a dozen mongrel processes, ensuring they stay running, starting and stopping them all. One command, one process.

Of course this is a preview...we expect to see bug reports and find issues with it. For example, it currently deploys under a context rather than at the root of the server, so my app above would be available at http://localhost:8080/testapp instead of http://localhost:8080/. That's going to be fixed soon (and configurable) but for now you'll want to set the following in environment.rb:
ActionController::AbstractRequest.relative_url_root = "/<app name>/"
ActionController::CgiRequest.relative_url_root = "/<app name>/"

And of course, you're going to be running JRuby, so you'll need to take that into consideration. JRuby's general Rails performance still needs more tweaking and work to surpass Mongrel + Ruby, but out of the box you already get stellar static-file performance with the GlassFish gem...something like 2500req/s for the testapp index page on my system. The remaining JRuby performance is continuing to improve as well...we'll get there soon.

So! Give it a try, report bugs on the GlassFish issue tracker, and let us know on the GlassFish mailing lists what you'd like to see improved.

Mongrel...your days are numbered.

25 comments:

Anonymous said...

I'll believe it when it runs our app without puking about ARGV not being defined. Oh, and when it can actually handle file uploads without falling over.

Charles Oliver Nutter said...

anonymous: Truly! Both issues are known and will be fixed soon. The first relates to how GlassFish is embedding JRuby, and the second...well it got fixed in GF V2, so hopefully we can track down what fixed it.

Anonymous said...

Could you publish a benchmark of Glassfish vs. Mongrel? Including memory usage?

Unknown said...

Also, what is the requirements list to run on glassfish vs MRI?

Anonymous said...

C:\jruby>
Failure to install on Win XP and Jruby 1.0.1


jruby bin\gem install glassfish-gem-10.0-SNAPSHOT.gem
Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
Error instaling glassfish-gem-10.0-SNAPSHOT.gem:
ERROR: Failed to build gem native extension.

rake RUBYARCHDIR=C:/jruby/lib/ruby/gems/1.8/gems/GlassFish-10.0.0-java/lib RUBYL
IBDIR=C:/jruby/lib/ruby/gems/1.8/gems/GlassFish-10.0.0-java/lib extension
'rake' is not recognized as an internal or external command,
operable program or batch file.


Gem files will remain installed in C:/jruby/lib/ruby/gems/1.8/gems/GlassFish-10.
0.0-java for inspection.
Results logged to C:/jruby/lib/ruby/gems/1.8/gems/GlassFish-10.0.0-java/ext/glas
sfish/gem_make.out

Anonymous said...

I appreciate another deployment option for JRoR apps. But I think the claim "The End Is Near For Mongrel" is an invitation to the usual kind of Java/Ruby flame wars. I'd rather try to avoid that

Arun Gupta said...

Anonymous, Windows installation instructions are available at: http://blogs.sun.com/arungupta/entry/announcing_glassfish_gem_for_rails. Are you in the directory where gem is available ?

If the gem is in current directory, then the following command will work:

\jruby-1.0.1\bin\gem install glassfish-gem-10.0-SNAPSHOT.gem

Charles Oliver Nutter said...

iak: I'd love for that to happen...the only real question is "what should that look like?" The Rails module in Grizzly could easily be expanded to support deploying arbitrary Ruby application types, but those application types would probably need some modification to meet it half-way. For example, The current module is Rails-specific because it manages the Rails instances, sessions, and so on directly. I could see that a generic deployment mechanism might allow you to deploy a specific Ruby file, and that could register services and manage resources. Hmm...we should talk more.

Anonymous said...

It's great if GF simplifies deployment. What about RAM? Mongrel costs about $20 to $30 a month for a small-audience Rails app on a 256 MB VPS. Additional apps are about $10 a month. How does GF compare? Simpler combined with lower cost would be really cool.

On another issue, it remains to be seen if Mongrel's days are numbered. A major part of my interest in Ruby and Rails is to get as far away from Java as possible. After what I've been through, I kind of don't even want to hear the word "Java" or J-anything. I don't think I'm alone in feeling that way.

I'm guessing JRuby and GF will have to not merely match but decisively exceed (Apache|Nginx|Lighty) and Mongrel to capture individual developers and small startups. I'm not sure about big organizations though. That could be a whole other story.

Anonymous said...

eeby

Your not alone and now it appears that Sun is getting real cozy Microsoft. I tried NetBeans (It's very good!) and actually was warming up to to using jRuby when it was dictated that a Java platform MUST be used. But Sun/MS or Novell/MS are things I personally will try to avoid.

Daniel Berger said...

"...the power and simplicity of deploying to a Java application server."

Haha, very funny. Let go, Charles.

Timothy Wee said...

end is near for mongrel.. if jruby overtakes the C-version of ruby.
Though grizzly is certainly a great server, esp. since it uses java nio inside =)... (kinda similar to python's twisted)
go reactor pattern!

Tim Wee

Anonymous said...

@Eeby:

Why do you care if your Ruby program runs on the JVM? JVM is a very good virtual machine. I can understand that you may have had enough of the Java programming language, but the JVM is just a VM...

Unknown said...

I'm not worried about deployment -- quite the opposite, I've no need for it and would never use it (since Puppet itself is a deployment/management tool).

I just want something that is easy to manage and can spread the load across all cores. And client certificates. :)

I currently use pretty normal XMLRPC for all of the services Puppet provides, but I'm working on switching to REST (hopefully to be released next month), FWIW.

James Britt said...

Great for folks using Rails. Will there be a similar option for the many people using Nitro or Ramaze or IOWA or Merb or Camping or Cerise for their Web applications?

Not everyone wants or needs the bulk of Rails, and having an agile JVM deployment alternative for the many other Ruby Web frameworks would rule.

Unknown said...

Catchy title, but fortunately it doesn't mean an end for Mongrel if you don't want Java on your server (like me for example). C-Mongrel is doing fine, serving hundreds of thousands of reqs from my app servers everyday and is not going anywhere soon (and so is Java I suppose :-P. Anyway, it's good to have yet another deployment option.

Anonymous said...

Awesome with the simple deployment scenario! I have done some benchmarking and unfortunately the glassfish_rails + JRuby 1.0.1 seems really slow :-(

For a simple action that shows the title of a book model, I get 10-11 req/s using glassfish_rails and with a single Mongrel I get around 75 req/s? (measured using ab).

Am I doing something wrong?

Tim O'Brien said...

Fucking brilliant! I mean I don't use Glassfish, but this is a reason to try it out.

kevwil said...

I'm with James Britt on this one. The end of Mongrel would mean the end of Merb, and that would be a bad thing indeed. Rather than all this futzing around with heavy Java app servers, why not create JMongrel? Or both, I guess.

labria said...

I made some test and it seems that a JBoss installation is really faster and consumes less memory than a GlassFish deploy, when dealing with Rails apps.

Senthil Nayagam said...

Hi,

I love in theory the concept of a multithreaded application server (I used to love apache with mod-php, when I was a php developer).

I have made some production deploys and still not very happy with current hosting options
which include
nginx as load balanced reverse proxy
mongrel cluster to run/manage the mongrel processes
mongrel as Rails Runner
monit to monitor the processes and restart them
process daemons to see server CPU and memory usage is within limits

I am not talking about mysql, mail etc as they are on seperated servers.

but java on linux is not for beginner users(installing would leave a bad taste unless some experienced guy helps you out).

also there are some gems/libraries which are not ported/portable to jruby currently, like openssl, rmagick, etc

you have made a tall claim, let us see if something comes out usable

regards
Senthil

Anonymous said...

Shouldn't the first command be:
jruby -S gem install glassfish-gem-10.0-SNAPSHOT.gem

Currently, you don't have "jruby -S"
gem install glassfish-gem-10.0-SNAPSHOT.gem

Anonymous said...

This is amazing: Over the last 2 months I built a moderately complex rails app (well over 5k LOC, 70 classes), and just ran it under GF with your single command. It works flawlessly.

Response time is slightly degraded compared with apache/mongrel but not significant. This will allow me to use the iText PDF library from my rails app (previously I had to use a Java bridge). Rock on!

Anonymous said...

@k-dub: there is a jmongrel, see http://ola-bini.blogspot.com/2007/04/mongrel-in-jruby.html

Pramod Gopinath said...

I have pushed out a new version of the glassfish V4 JRuby gem on RubyForge. You could download the gem by running the command 'gem install glassfish' from your JRuby installation. For the gem to run in the JRuby environment you do not need to add a JRUBY_HOME environment variable to be set in the asenv.conf file.
Further details can be obtained from my blog entries latest being : http://blogs.sun.com/pramodg/entry/glassfish_v3_gem_v0_11