Closing your connections

Recently, we have had a spate of connection leak problems in our JMS operations in production. On analysis we found that a few of our applications are not closing the JMS connections properly. In this entry, I am going to talk about how to close your JMS connections and ways of detecting any connection leaks.

In any JMS operation, you would
a) open a connection to the JMS resource,
b) establish a session and
c) create a producer or a consumer to send or receive messages.
When you create a JMS connection, the container allocates resources on the resource provider. Therefore, the application should be responsible for ensuring that these resources are de-allocated at the end of the operation. From a programming context, this is achieved by calling connection.close().

The application should ensure that the connection.close() is being called irrespective of the outcome of the operation. i.e., it should be called even under exception scenarios. This is typically achieved by closing the connection inside the finally block.

There is generally a confusion about whether closing a connection alone is sufficient or whether the underlying session and the message producer or message consumer should also be closed. The JMS 1.1 spec clearly states that closing a connection alone is sufficient. When a connection.close() is invoked it tells the container that all the constituent objects of that connection should also be closed.

Now, once we have coded everything correctly, we should make sure that we are not leaking connections. How do we identify that? There are a couple of unix commands that I use to make sure that my code is not leaking connections. When we open a connection, a TCP communication channel is opened between your application and the resource provider. In the case of AQ, it is a connection from your JVM to the AQ database. So if we monitor the number of connections that are open between your server and the AQ database, we can find out if there is a leak or not.

One way is to use the netstat command. You can use netstat -an grep 1521 grep dbhost wc -l to get the number of connections opened from your server to the AQ database.

But there is a problem here. We have multiple oc4js running from 1 server. So we will not be able to identify whether the connections are coming from your oc4j or another oc4j. There is another command in unix called lsof which lists all the open files. In unix, a socket is again a file. If you execute the command lsof -i :1521 grep dbhost grep pid wc -l it will give the number of open connections from your oc4j to the AQ database. Here pid is the process id of your oc4j.
Give it a try and let me know your thoughts.