Dead Glassfish Connections

Running a complex web application with sessions and connections to the DB, MQ and HTTP clients brings you sooner or later into a discussion or problem with connections that have not been properly terminated by Glassfish or the client. Depending on the time-out settings in the OS and in Glassfish you might face CLOSE_WAIT connections. What is causing this is topic by itself, also helping the system to get rid of it. At the end quite likely the problem lies somewhere in the sourcecode.

In my case we found a large number of CLOSE_WAITS to Glassfish with strange IP addresses (closed enterprise app but open to public web).

Here only some helpful scripts (Linux/Ubuntu):

Find the Glassfish PID

jps | grep ASMain | awk '{ print $1 }'

#get it into variable
pid=$(jps | grep ASMain | awk '{ print $1 }')

Show all socket connections

netstat -anp | grep ESTABLISHED
netstat -anp | grep CLOSE_WAIT

Show all connections to Glassfish

netstat -anp | grep CLOSE_WAIT| grep $(jps | grep ASMain | awk '{ print $1 }')
netstat -anp | grep ESTABLISHED| grep $(jps | grep ASMain | awk '{ print $1 }')

Still a bit hard to review

netstat

netstat

Now lets sort by IP and count it (ignoring the ports)

netstat -anp | grep CLOSE_WAIT| grep $(jps | grep ASMain | awk '{ print $1 }')|awk '{print $5}'|awk -F':' '{print $1}'|sort -k1|uniq -c

Creates a list like this (number of connections and the related ip address)

netstat summary

netstat summary

You can pack this int a cron job or even get it combined with a geolocation webservice to find the user.

Evaluating JVM Heap Dumps

Despite running JVM supposedly being rock-solid and stable I see enough JVM who cant take the load, most likely to non-optimal settings, throwing heap dumps.
A while ago I struggled to open Thread Dumps I can open heap dumps with VisualVM (Version 1.3.7 at the time of writing)

VisualVM

VisualVM

Heap Dump File

Heap Dump File

Beware, with significant heap dump files (in my sample 700MB) it can take quite a while to open or review the results. Open thread dump list took a good 10 minutes.

Long Processing Times

Long Processing Times

Hide Glassfish Server Information

Despite moving on to JBoss progressively I still share my findings, often they apply to other products too.

For a public facing server you want to reveal as little background information as possible. In Glassfish you can hide create custom 404 and 500 error pages (previous post), but you should also hide the server info that comes with the server header, easily revealed by a tool ike the Firefox plugin httpfox.

Response Header

Response Header

There are 2 crucial settings you must change:

  • JVM setting for product name: -Dproduct.name=”My App Server”

    JVM Settings

    JVM Settings

  • Remove the “XPowered By” flag

    XPowered By

    XPowered By

As result you will have a pretty generic response header

Response Header

Response Header

Oracle abandons Commercial Support for Glassfish !

I could not believe it when I read this in my daily serving of IT news. But it is the truth, Oracle will stop the (commercial) support for Glassfish in 2016 !
I remember a)  the full blown announcements during the take-over from SUN they would continue with Glassfish and b) people questioning it, the later should be right now. Ultimately, even Oracle saying they would continue with the community edition, means Glassfish will be dead, the core team will shrink and Glassfish becomes a hobby in order to maintain the reference EE implementation (to control the other players). They killed OpenOffice, OpenSolaris, Hudson CI (pretty much). I spent a lot of time with Glassfish and right now rolling it out to customers who actually expect commercial support, this back-stabs my efforts in the last few years being a Glassfish fan.

Dear Oracle, I will not continue with WebLogic  Application Server (another closed product), but swing over to JBoss (for which I did some compatibility tests for our applications anyway the last 2 years)

So Long, and Thanks for All the (Glass)Fish !

Update:

Glassfish Tuning and Thread Dumps

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:

  1. jstack
    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
  2. asadmin
    Go the Glassfish_HOME/bin folder and execute
    ./asadmin --user admin generate-jvm-report --type=thread > threaddump.txt
  3. 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.

tda tool

tda tool

Some References

Monitoring Glassfish V3.1.2 Options

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.

JConsonsole

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.

JConsole

JConsole

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

Glassfish and https running secure applications

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)


iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8181
iptables-save -c > /etc/iptables.rules
iptables-restore < /etc/iptables.rules

vi /etc/network/if-pre-up.d/iptablesload
#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

Additionally you can get a proper SSL certificate to stop annoying the user with a no proper certificate warning. See previous tutorial here.

SSL Error

SSL Error (Chrome)

If you operate an enterprise application with a known URL to the users, unlike a regular website where the portal should be reached with regular http, I would completely disable regular http.

Disable http

Disable http