GlassFish Adoption Questionnaire response from Involver.com by Mike Wadhera.
Date: Feb 2009

Can you tell us about the application, site, or service in which you have adopted GlassFish?
We run Involver.com on a JRuby on Rails stack with GlassFish as our primary web and application server.

Involver is a video marketing platform used to distribute and track video campaigns on social networks. Our customers include big brands such as Puma, Nissan & Chiquita as well as non-profits like Save Darfur and Kiva.org.






Our platform enables these organizations to harness the power of video on social networks to create engagement with influencers, raise brand awareness and drive traffic to their online properties.

At the heart of our platform is a Ruby on Rails application running under JRuby 1.1.6 served by GlassFish v2ur2 powering our video player, white-label Facebook apps & website.

How and when did you first find out about GlassFish?
We first heard about GlassFish about 6 months ago when looking at open source Java application servers. I believe it was a blog post by Arun Gupta highlighting the use of GlassFish for hosting JRuby on Rails applications that piqued our interest.

Did you go through an evaluation process before selecting GlassFish?
First a bit of history to provide some context...

Our production stack originally consisted of the typical "pack of mongrels" fronted by a dedicated HTTP reverse-proxy most Rails sites employ. We also had several periphery ruby processes running background work such as Facebook API updates as well as a Merb-powered ad server. As our platform started to evolve, we quickly realized that this approach left us managing a large amount of OS processes. Furthermore, the inability to share resources between processes meant that we had to keep several copies of our (large) Rails environment in memory. Put simply, this deployment strategy wasn't an efficient use of resources, both human and machine. So we started to look at alternative solutions.

Around this time, we were reading about the impressive strides the JRuby team was making with Rails compatibility and I was intrigued about the possibilities of integrating with Java. The language has an ecosystem rich with mature libraries and standardized software frameworks -- useful for tackling complex requirements such as ours. I also really liked the idea of packaging and deploying our web applications as WARs into any application server of our choice & the ability to run several apps in a single container. More importantly, we realized that the runtime pooling feature of JRuby would enable an elastic cluster of Rails environments, which meant we would only have the overhead of a full cluster during periods of high traffic -- when it was most needed. All this, with only a single JVM process to monitor, quickly convinced us about deploying with Java.

When it came time to look at application servers we evaluated several different solutions such as JBoss, Tomcat and GlassFish and we arrived at GlassFish for a couple key reasons...

First, we felt confident knowing that the project was sponsored commercially by Sun & that the core team had a well-defined public roadmap and release cycle. Second, the high degree of community overlap between the JRuby & GlassFish projects greatly influenced our decision. For instance, the blog posts by the GlassFish team illustrating the use of JRuby runtime pooling for Rails applications made us feel comfortable that the two technologies would play well together "out of the box". Also, it was reassuring to know that there were experts at the intersections of these tools whom we could turn to for help during our deployment.

I should also mention that the GlassFish Admin console played a large role as it shielded us from managing verbose XML configuration files; Setting up database connection pooling over JDBC was point-and-click as was configuring the embedded OpenMQ broker. This greatly reduced setup-cost, especially during the initial testing/evaluation period.

What specific version of GlassFish are you using?
We use GlassFish 2.1 build 60e. We had some problems with the embedded JMS broker in the official v2ur2 release, so we gave the latest promoted build a shot & it ended up solving the issue.

On what operating system do you run GlassFish? 
Our production servers are Debian Linux using the 2.6 kernel. For development we use Mac OS X Leopard.

On what hardware platform do you run GlassFish? 
Our application servers are 8GB, 8-core Xeon boxes.

Have you purchased a GlassFish subscription?
We haven't yet looked into the subscription model.

What specific features or modules of GlassFish are you using?
So far: WAR-based deployment, JDBC, JMS, alternate docroots (for Rails page caching) & currently looking into JMX. We also make use of the vhosting capabilities of GlassFish to run several separate applications that make up our full suite. This capability has greatly simplified server management.

Are you using OpenMQ?
Yes. We are using the JMS feature in JRuby Rack to queue asynchronous messages into an OpenMQ broker from within our Rails app.

I've personally used several asynchronous solutions such as BackgroundRB & BackgroundJob, even rolled my own with a Thrift-powered job server. The JMS queues approach in JRuby Rack is the simplest, most robust solution I've seen yet for dealing with "long running" tasks in single-threaded Rails environments as it leverages the same runtime pool already setup for HTTP traffic. The self-managed GlassFish OpenMQ broker also makes deployment trivial. I want to thank Nick Sieger and the JRuby Rack team for doing an awesome job at making these Java server technologies easily accessible to the everyday rubyist.

What do you like most about GlassFish?
Just how smooth our transition has been as JRuby on Rails users; The community is fairly large and has been helpful to us. Also the performance is very impressive & again we are big fans of the web-based admin console.

What would you most like to see improved in GlassFish?
The PermGen memory leak on re-deploys has to be addressed. As JRuby users, the PermGen is a heavily used area of memory by our applications -- which has accelerated the effects of the leak; We have had to restart our GlassFish instances after as few as 2-3 deploys on some servers.

Also looking forward to the modular design of v3 as we would welcome the faster startup/deploy/shutdown times.

Are you using any open source or commercial frameworks or tools in your application?
We are big believers in open source. We use open source frameworks like Ruby on Rails & Merb, as well as JRuby.

Does your application use a database? If so, which one?
Our RDBMS of choice is MySQL. We use version 5.1 with the most recent release of the MySQL Connector/J JDBC drivers.

Are there any figures about the scale of your adoption which you would like to share ?
We don't release public stats on internal numbers. However, it is worth noting that our larger customers do a million-plus video impression runs with us at a time, each impression resulting in multiple logging messages on the back-end. So between that, our Facebook apps & self-serve website, we do quite a bit of monthly traffic.

How has GlassFish performed since your application went live?
For the most part, pretty well. We've been happy with the performance so far. More recently we have been struggling with dealing with the aftermath of the memory leaks -- it has actually resulted in a few instances of GlassFish going down, causing some restless nights for us this past week. We tend to cycle our GlassFish servers more frequently now, but obviously this is a sub-optimal solution.

How would your describe your participation in the GlassFish project ?
We're pretty much user-only right now -- though I could see us playing a more active role in the next release by providing testing, filing bugs that sort of thing. We have a fairly large Rails app that could help put v3 through it's paces.  :-)


Thanks Mike for taking time to fill up the questionnaire!