How to find out if JMS Connection is there?

Question

In JMS it is easy to find out if a connection is lost, a exception happens. But how do I find out if the connection is there again?

Scenario: I use JMS to communicate with my server. Now my connection breaks (server is down), which results in a exception. So far so good. If the server is up again and the connection is reestablished, how do I know that?

I don't see any Listeners which would facilitate such information.

Answer 1

JMS spec does not describe any transport protocol, it does not say anything about connections (i.e. should broker keep them alive or establish a new connection for every session). So, I think what you mean by

Now my connection breaks (server is down), which results in a exception.

is that you are trying to send a message and you are getting a JmsException.

I think, the only way to see if broker is up is to try to send a message.

Answer 2

Your only option in the case of a Connection based JMSException is to attempt to reestablish the connection in your exception handler, and retry the operation.

Answer 3

Ahhh...the old exception handling/reconnection conundrum.

There are some transport providers that will automatically reconnect your application for you and some who make the app drive reconnection. In general the reconnections hide the exception from the application. The down side is that you don't want the app to hang forever if all the remote messaging nodes are down so ultimately, you must include some reconnection logic.

Now here's the interesting part - how do you handle the exceptions in a provider neutral way? The JMS exception is practically worthless. For example, a "security exception" can be that the Java security policies are too restrictive, that the file system permissions are too restrictive, that the LDAP credentials failed, that the connection to the transport failed, that the open of the queue or topic failed or any of dozens of other security-related problems. It's the linked exception that has the details from the transport provider that really help debug the problem. My clients have generally taken one of three different approaches here...

1. Treat all errors the same. Close all objects and reinitialize them. this is JMS portable.
2. Allow the app to inspect the linked exceptions to distinguish between fatal and transient errors (i.e. auth error vs. queue full). Not provider portable.
3. Provider-specific error-handling classes. A hybrid of the pother two.

In your case, the queue and topic objects are probably only valid in the context of the original connection. Assuming a provider who reconnects automatically the fact that you got an exception means reconnect failed and the context for queue and topic objects could not be restored. Close all objects and reconnect.

Whether you want to do something more provider-specific such as distinguish between transient and permanent errors is one of those "it depends" things and you'll have to figure that out on a case-by-case basis.