Once you get into a production like stage with more data volume, more users, etc. you will find yourself pretty fast in the situation where Glassfish gets some hickups or slowness. An expected situation if you did not change the default parameters out of the box which are chosen to make Glassfish to run even on a small box.
We ran into some kind of concurrency problems with JDBC pools and thread where Glassfish appeared to be hanging. One approach is to create thread dumps for the JVM.
With Glassfish we have a few options:
Run jps which returns you the list of applications running a JVM, choose the PID and execute
jstack <PID> or jstack -F <PID> > td.log
Go the Glassfish_HOME/bin folder and execute ./asadmin --user admin generate-jvm-report --type=thread > threaddump.txt
kill -3 <PID>
Supposed to create a dump in the default log folder of Glassfish. Doesnt work for me.
With the (or better more than 1) file at hand you can evaluate them by hand or use some of the tools around. I am still struggling to make the tool analyzing my dumps. They simply open the files like a editor.
There are 2 crucial phases you want to look under the hood of your running Glassfish or inside the JVM underneath: Performance Tuning and Health Monitoring during production.
With JMX (Java Management Extensions, Wikipedia) at hand, there are a few options to choose from.
The graphical monitoring tool is great for local deployment, it allows you to connect to a JVM on the same host or a remote host. It creates line graphs for your for all relevant from the moment you connect, it is perfect to observe a server while you do some testing or other actions, though it does not record any values while you are not connected. I have a hard time to get it running on a remote server and I do not favour the ‘open’ approach (see previous blog entry) which allows anyone to access the JVM with the disabled authentication settings. I also had situations where the JVM was frozen and it was no longer possible to access the JVM for monitoring, here I would rather have snapshots before the problem started together with server.log.
Glassfish Rest Interface
Note: You need to enable the areas you want to monitor with the admin console (or the asadmin command line) because per default all are OFF. Continue reading →
By default Glassfish listens to http on port 8080 and https on port 8181.
It is better to listen to the default ports 80 for http and 443 for https, usually you dont want the user to enter port numbers as part of the URL.
Even the Glassfish Admin Console allows to change the ports (Configurations/Server Config/Network Config/Network Listener), certain server OS such as Ubuntu do not allow non-root users (you should run Glassfish as separate user !) to ports below 1024. We can achieve this by port rerouting with the iptables command (under Ubuntu)
After almost 3 years (see previous post) I revisit the topic this time using the latest version og Glassfish 3.1.2 and GoDaddy as certificate provider. I created a certificate for a sub-domain (sub.whateverdomain.com) this time and make use of the extremly cheap 5.99 U$/year offer (no wildcard included)
Note: you need to re-deploy the resource adapter with version 5.7 and check all connector settings.
It works fine with Glassfish 220.127.116.11 and Java JDK 1.7.07
I had issues with the firewall due to fact ActiveQM uses a fix registration port for JMX but dynamic ports for the communication port. The web-console was not accessible. “Exception occurred while processing this request, check the log for more information!”
[#|2012-10-18T07:42:09.249+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=73;_ThreadName=Thread-2;|StandardWrapperValve[jsp]: PWC1406: Servlet.service() for servlet jsp threw exception
java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
There are ways to configure this for a standalone ActiveMQ instance with the parameters connectorPort and rmiServerPort but I didnt find out yet how to do this with the embedded version.
As a workaround I changed this setting -Djava.rmi.server.hostname from my hostname to localhost. -Djava.rmi.server.hostname=localhost
As much I like to use Glassfish, customers might have different taste or policy. We are challenged now to run our EJB/Web-application on JBoss as well. Netbeans supports JBoss up to version 6 but not the latest version 7 which is fully EE6 web profile compatible. Version 7 is not (yet) supported due to major revamp of the management API of JBoss. I found one plugin provided by Oleg Kulikov on github, a working prototype that can control Jboss 7 server from Netbeans, but cannot deply an application to it or debug it. I wish I know more about Netbeans RCP development, but it is not an easy task to create this kind of highly integrated NB plugin. Discussion as Netbeans issue here.
Once you have any serious sized application running on Glassfish, you need to profile and tune your server settings. A good tool to look under the hood of a running Glassfish is to to connect jconsole (part of JDK) to its JVM. This works without problem for a local Glassfish but when it comes to a remote instance you cant connect to the default Glassfish setup.