GlassFish logo Ubuntu logo
Installing GlassFish 3.1.2.2/4.0 on Ubuntu  (last updated 2013-11-15)

This HOWTO explains one way of setting up GlassFish 3.1.2.2 under Ubuntu; it's how we do it where I work. I've also been working with GlassFish 4, and haven't found anything here that doesn't work with that version. Questions or suggestions for improvement can be addressed to shadowm at lyonlabs dot org.

Installing GlassFish
Fronting GlassFish with Apache
Setting up Database Connection Pools
Problems with Persistent Timers

Installing GlassFish

back to top

Fronting GlassFish with Apache

Many people use Apache to handle redirects, SSL, &c., while leaving the heavy lifting to GlassFish. Here is one way to do this, using the Apache AJP connector.

back to top

Setting up Database Connection Pools

Here are the steps to set up a connection pool for a PostgreSQL database: For those using MySQL, the datasource class name is com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource. The necessary properties are user, password, and URL; the format for URL is:
jdbc:mysql://<hostname>:3306/<databasename>

Problems with Persistent Timers

We had no end of problems with EJB timers in earlier versions of Glassfish v3 (we use the @Schedule annotation for this). This may be fixed in 3.1.2.2, but here's the background anyway:

Sometimes, whether redeploying or just restarting GlassFish for whatever reason, the timers would not start again. Eventually, we learned that timers are persistent by default. The next step was to investigate how GlassFish was restoring these timers, which led us to this URL (visit it on the machine running GlassFish):

http://localhost:8080/ejb-timer-service-app/timer

On a machine that should have eight timers (eight @Schedule annotations in the app's code), we saw one machine with 31 persistent timers, and one with 35! Clearly something was amiss. After a discussion on the GlassFish mailing list, I was able to send a dump of the timer database to someone at Oracle, which brought me to the next interesting bit of information: how to directly examine and alter the JavaDB database containing persistent timer statistics. Note that to connect to this database, you must either stop GlassFish or copy the directory containing the database somewhere else (and adjust the connect statement below).

These are the steps we followed: (adjust for where you've installed GlassFish and which user owns it):

su - glassfish
export DERBY_HOME=/usr/share/glassfish-3.1.2.2/javadb
$DERBY_HOME/bin/ij
connect 'jdbc:derby:/usr/share/glassfish-3.1.2.2/glassfish/domains/<domain-name>/lib/databases/ejbtimer';
select * from EJB__TIMER__TBL;
Once you're connected, number of records in EJB__TIMER__TBL should equal the number of @Schedule annotations in your code. In our case, we saw many duplicated entries. We didn't feel we could afford the time to diagnose the issue, and there was no real reason for the timer jobs to be restored if they had passed their expiration time while GlassFish was not running, so we just prepared a build with persistent=false in all the @Schedule annotations, and deleted all the records from the timer table before deploying it. Now we consistently see eight non-persistent timers, and that number doesn't change even after redeploys, GlassFish restarts, or bringing GlassFish down hard and restarting it.

back to top