JMS Connection Pooling in Message Listener

Question

Currently i'm working on a standalone Java apps that connects to a Websphere MQ to send and receive messages.

The flow is in asynchronous mode, which we implemented using MessageListener class to retrieve the messages from the queue when they are ready. The code to initialize the consumer with the listener is as follow:

if(connection == null)
        connection = getJmsConnection();

    try {
        session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        if (isTopic) {
            destination = session.createTopic(destinationName);
        } else {
            destination = session.createQueue(destinationName);
        }
        consumer = session.createConsumer(destination);
        consumer.setMessageListener(listener);
    } catch (JMSException e) {
        e.printStackTrace();
    }

The getJmsConnection() method will return a connection from a pool, implemented using Apache Commons Pool library.

My question is, will the connection assign to the listener from the pool be active and tied to that listener as long as the program is running? Or the connection is used intermittently and can be reuse by other processes? Our idea is to have the sending and receiving process to reuse the connection from the pool, but i'm not sure how the MessageListener deal with the connection they are assigned with.

Thank you.

Answer 1

The key object here is the session rather than the connection; the session is on the one that will be doing the primary work here with the message consumption (async or otherwise).

It is advisable to try and share out the connection as widely as possible. Temporary destinations are scoped on the connection level. So the use of pooling is a good idea; it will be perfectly possible to share that connection around.

However I would also say that it might be worth considering pooling the sessions. With the code here a new session will be created, each time through that code, that will mean a new connection to the WebSphere MQ queue manager will be created. It's not clear what the scope of that will be, but if that is closed quickly it could become a bottleneck.