This HOWTO explains one way of setting up GlassFish 3.0.1 under Ubuntu; it's how we do it where I work. When we upgrade to GlassFish 3.1.1 later this year, I'll update this file. Questions or suggestions for improvement can be addressed to shadowm at lyonlabs dot org.Installing GlassFish
export PATH=/usr/share/glassfish-3.0.1/glassfish/bin:$PATHLog out and back in to make the change take effect.
addgroup --system glassfish adduser --system --shell /bin/bash --ingroup glassfish glassfish
glassfish soft nofile 32768 glassfish hard nofile 65536You will also need to add this line in /etc/pam.d/su:
session required pam_limits.so
chown -R glassfish.glassfish glassfish
asadmin start-domain <domain-name>
touch /var/log/glassfish-3.0.1 chown glassfish.glassfish /var/log/glassfish-3.0.1Verify that the script works by running it as root:
-client -Xmx512mwith these:
-server -XX:+AggressiveHeap -Xmx1400m -Xms1400m -Xss128k -XX:+DisableExplicitGC
<IfModule mod_jk.c> JkWorkersFile /usr/share/glassfish-3.0.1/glassfish/domains/<domain-name>/config/workers.properties JkLogFile /var/log/apache2/mod_jk.log JkLogLevel error JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkRequestLogFormat "%w %V %T" JkMountCopy all </IfModule>You'll also need to tell Apache to forward any traffic for your GlassFish-hosted web app; it's also a good idea to disallow access to the WEB-INF directory. If your app's context is /myapp, add lines like this to the file:
JkMount /myapp/* ajp13 <Location "/myapp/WEB-INF/"> deny from all </Location>
worker.list=ajp13 worker.ajp13.type=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 # load balancing only: worker.ajp13.lbfactor=50 connection_pool_size=10 connection_pool_timeout=600 worker.ajp13.socket_keepalive=False # make same as GlassFish: worker.ajp13.socket_timeout=30
<?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"> <persistence-unit name="your-PU-here" transaction-type="JTA"> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <jta-data-source>jdbc/your-resource-here</jta-data-source> <exclude-unlisted-classes>false</exclude-unlisted-classes> <properties> </properties> </persistence-unit> </persistence>
jdbc:mysql://<hostname>:3306/<databasename>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):
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. I'm not sure whether this is a bug in GlassFish (and of course, 3.1.1 has been released since then), although I did send a dump of the timer database to someone at Oracle. Which brings us to the next interesting 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.0.1/javadb $DERBY_HOME/bin/ij connect 'jdbc:derby:/usr/share/glassfish-3.0.1/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.