Friday, September 14, 2007

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.

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.

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:

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.

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.

rake RUBYARCHDIR=C:/jruby/lib/ruby/gems/1.8/gems/GlassFish-10.0.0-java/lib RUBYLIBDIR=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/glassfish/gem_make.out

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.

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.

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.

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!

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.

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.

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 optionswhich includenginx as load balanced reverse proxymongrel cluster to run/manage the mongrel processesmongrel as Rails Runnermonit to monitor the processes and restart themprocess 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

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