Is maintenance on long lived JMS connections necessary?

Question

I keep a JMS connection always open, because I have a MessageListener on it.

Is it a common need to worry about minimizing maintenance of applications with long lived JMS connections?

I was thinking something along the lines of try to recover from some possible common well known kinds of failure, like temporary connectivity failure.

Answer 1

Your will need to handle two cases:

1. Firewall between you and the JMS server. Most firewalls will cut an "idle" connection after a couple of hours. If this is the case, send a message every hour or so or, if you can, enable TCP_KEEPALIVE. This is a TCP/IP option which will cause the underlying socket to send a test message after some time.
2. The other server is rebooted. When this happens, you'll get an "connection lost" error when you try to send the next message. In this case, just open the connection once more and try again.

I suggest to install a local JMS server (any will do), connect your app to it and stop the server. That will give you the error message to expect for case #2. Then write a unit test with MockRunner to make sure your error handling is correct.

Answer 2

A good JMS provider will deal with network outages such as a dropped socket or a message broker failing over or being rebooted. e.g. here is how you enable automatic reconnection in Apache ActiveMQ.

Its often quite a pain to recreate all of your JMS resources (connection, sessions, producers, consumers) - its much easier for the JMS provider to do it for you.

If you must use a provider which can't support this feature - consider either switching, or using the Spring JMS helper classes which can do some of this for you.

Answer 3

There's nothing in the standard JMS spec that I know of that ensures that connectivity troubles won't be visible to the application. Maybe there are some vendors who do this as an extension (as James Strachan suggests).

If you want a robust JMS client that isn't dependent on vendor extensions, you need to handle errors and do reconnection. See http://stackoverflow.com/questions/47683/reconnecting-jms-listener-to-jbossmq#117503 (which, despite the title, isn't JBossMQ-specific).