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.
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.
ReplyDeleteanonymous: 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.
ReplyDeleteAlso, what is the requirements list to run on glassfish vs MRI?
ReplyDeleteC:\jruby>
ReplyDeleteFailure 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
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
ReplyDeleteiak: 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.
ReplyDeleteIt'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.
ReplyDeleteOn 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.
eeby
ReplyDeleteYour 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.
"...the power and simplicity of deploying to a Java application server."
ReplyDeleteHaha, very funny. Let go, Charles.
end is near for mongrel.. if jruby overtakes the C-version of ruby.
ReplyDeleteThough grizzly is certainly a great server, esp. since it uses java nio inside =)... (kinda similar to python's twisted)
go reactor pattern!
Tim Wee
@Eeby:
ReplyDeleteWhy 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...
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?
ReplyDeleteNot everyone wants or needs the bulk of Rails, and having an agile JVM deployment alternative for the many other Ruby Web frameworks would rule.
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.
ReplyDeleteAwesome with the simple deployment scenario! I have done some benchmarking and unfortunately the glassfish_rails + JRuby 1.0.1 seems really slow :-(
ReplyDeleteFor 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?
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.
ReplyDeleteI 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.
ReplyDeleteShouldn't the first command be:
ReplyDeletejruby -S gem install glassfish-gem-10.0-SNAPSHOT.gem
Currently, you don't have "jruby -S"
gem install glassfish-gem-10.0-SNAPSHOT.gem