JMS Connection in standalone client

Question

I am designing a standalone application (no app servers) which is going to invoke two timers every 5 mins and send (based on whether files are present in a director) and receive messages from a queue. This application is planned to run for a long time (years) continuously....

Now i am having a dilema whether to create a JMS connection only once and use it all the time.. or to connect the connection every 5 mins and close them... (after doing business logics)

Any suggestion on the design will be helpful? If i go for single connection (and use JMS MessageListenr), what will happen if the queue manager is down and comes after one or two days.......

I tried a sample with ActiveMQ... and as soon as i killed active mq broker and producer ... the listener thread (which creates conn only once and using MessageListener) application automatically ends after few mins

// Listener code below

    connectionFactory = new ActiveMQConnectionFactory(
            ActiveMQConnection.DEFAULT_USER,
             ActiveMQConnection.DEFAULT_PASSWORD,
            ActiveMQConnection.DEFAULT_BROKER_URL);
     connection = connectionFactory.createConnection();
     connection.start();
     session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE);
     destination = session.createQueue("mmy first active mq queue");

    MessageConsumer consumer = session.createConsumer(destination);
    MyListener mylistener = new MyListener();
    consumer.setMessageListener(mylistener);
    connection.setExceptionListener(mylistener);

Answer 1

In my opinion single connection will be a very bad choise for severel reasons:

1. Special cases (disconnections, falls and others), may cause your listener to fall (and not listen again).

2. Memory consumption of your Java may reach un-wanted levels.

3. Programs always need to change so working with one connection is not so dynamic.

The big advantage of queue is thah the messages it gets can stay for as long as we want, So if your program can work in a non syncronus way, there is no reason for goin with on connection.

Answer 2

In ActiveMQ going with one connection is possible and can be a good solution but of course it depends on the application. ActiveMQ provides the library that provides a Connection pooling mechanism you can make use of in your app. Instead of using the standard ActiveMQConnectionFactory you use the PooledConnectionFactory and under the covers the Connection instances your application uses are pooled for you.

Each time you need a connection the factory can return an unused Connection from the pool and each Connection can have a set of Sessions also pooled within it further lowering the amount of allocation and wire level chatter needed to spin up connections and sessions.

There are some interesting Blogs on the subject you can explore.

Pooled Connections in ActiveMQ Using ActiveMQ with Spring

Another place to look for code samples is in the ActiveMQ source itself, the module has several unit tests that show the pool in action.

Answer 3

With any messaging system you always face a requirement to let the program time out on connection retries at some point in order to raise an alert. For example, if your QMgr were in fact down for one or two days, you probably want the app to log that event within minutes of the connection loss rather than blocking waiting on reconnection attempts for two days without warning.

Given that requirement then, the first thing to do is to design the application to loop over a sequence that includes connection attempt to the messaging engine and exception handling. Within that loop you can assume a connection exists and either maintain a handle to the queue or open and close the queue as needed. Either drive the polling within this inner loop or else exit cleanly for each iteration and let the outer loop re-drive the connection as needed.

As long as that outer loop is in place, your app can run continuously regardless of loss of connection at the messaging engine side. (I'm using 'messaging engine' to avoid vendor-specific terminology such as queue manager for the generic portion of this reply.)

If you were to use WebSphere MQ, it is possible to do things like upgrade the QMgr whilst the application is running by using a multi-instance HA QMgr. The app will reconnect seamlessly to the running half of the QMgr with no code changes and you can use XA if you need 2-phase commit. In the event that the reconnect polling exceeds your configured threshold without finding a live QMgr, the app receives an error code which you can then use to raise an alert.

Finally, the question of whether the app should reconnect every 5 minutes makes no difference to the WMQ QMgr itself. Even if you were to use TLS channels, the additional load on the QMgr is negligible. The main consideration is channel startup times but with 5 minute polling that does not see to be a likely showstopper issue. Other transports may or may not have an issue with it but I'm not qualified to speak to them. As far as WebSphere MQ goes, no problems whatsoever. Even a small QMgr can handle thousands of simultaneous connections. The reconnect-on-each-poll method does have the advantage of throwing fewer errors in a noisy network environment. This is because it is easier to briefly obtain a connection and exit cleanly than to maintain a continuous connection over an unstable network. So if the app and server are in the same datacenter, either option works. If they are connected over a WAN and subject to firewall timeouts and other interruptions, then the shorter connections tend to be better.