glassfish in production

To run an J2EE application server like glassfish in production brings a lot of additional work after installation. While a simple installation for developers is easy, it seems no so easy today to bring glassfish in production. From my point of view, there are at least the following things to do for a production installation:

  • Add new user and group (e.g. glassfish) to /etc/passwd /and /etc/group
  • install latest jdk
  • install glassfish
  • setup and install start/stop scripts (smf on Solaris10)
  • install glassfish apache 2.2 ajp integration (example1 example2 example3)
  • configure glassfish logfile rotation
  • tune glassfish because default settings are not suitable for production ( a lot of parameters!)
  • harden glassfish because default security settings are not strong and secure enough
  • deploy jdbc configuration (jars + settings)
  • write scripts to integrate glassfish in your monitoring framework
  • write scripts to integrate glassfish in your deployment framework (e.g. Sun N1 SPS)
  • and of of course, this list is not complete

Nowadays, we have at least three (virtual) servers for each customer project. One for development, one for test and ond for production. This means to install and modify glassfish at least three times. But often, we also have hardware based load balancing in projects, that means to have at least two strings of glassfish for dev/test/prod or six installations alltogether!

Looking at the new glassfish V2 feature called application server usage profiles shows, that the three offered profiles (“developer”, “cluster”, “enterprise”) still leaking real production settings. A simple “production” or production-cluster profile would be nice. The production profiles should have tuned values (at least the parameters mentioned in the Sun Java System Application Server 9.1 PerformanceTuning Guide beginning on page 50) which makes it easier to setup glassfish for admins. The mentioned enterprise profile might be not the best for high traffic web 2.0 production web sites.

How do we do this job with other app servers? For a couple of customers, we’re using the Bea Weblogic Application Server. And we’re using the Sun N1 SPS Bea Weblogic module to install and configure Weblogic. N1 SPS also uses the possibility to run the WebLogic Scripting Tool (WLST) , which is a BEA tool for scripting the configuration of BEA WebLogic. WLST is a command-line scripting interface to monitor and manage BEA WebLogic Server instances and domains. The WLST scripting environment is based on the Java scripting interpreter, Jython.

Someting like this (GFST) would be cool to have for glassfish, too.


  1. Hi Kedar, that’s great to hear. I’ll post more input about GF in production and suggestions for the production profile. We’re currently working on a bigger project with about 16 GF2 instances each in one Solaris Zone where we need this.

  2. Mahesh says:

    I am deploying glassgish in Enterprises profile. Can some one help me in making light weight , As my purpose to serve only java request as good as switching server. For this i require absolute light weight GF.

Comments are closed.