Websphere MQ消息无限过程

Question

I am new to Message Queue. I am attemting to get messages from MQ Queue by using below code.

I am creating one connection and getting every message from the queue using that connection. Is it right way of doing like this and whether i need to commit the connection.

Infinite for-loop is right way to receive messages all the times from the queue, is it right? Kindly advice me.

try {
    createMQConnection(); // getting mq connection
    createMQSession(); // getting mq session
    createMQDestination(); // getting mq destination

    for ( ; ; ) { // infinite loop to receive message from Queue
        consumer = session.createConsumer(mqQueue);
        jmsTextMessage = (JMSTextMessage) consumer.receive(100);
        // Calling application method to process the requested message from queue
    }
} catch (Exception e) {
    throw e;
} finally {
    // closing consumer
    // closing session
    // closing connection
}

Answer 1

Is it right way of doing like this

Define "right." Depending on the business requirement, this could be right or it could be horrible. For example, with a 100ms wait time and a depth of zero messages the code will time out, throw a 2033 error (MQRC_NO_MSG_AVAILABLE), close the session, and exit. Is that what you want?

Generally there is a try / catch block enclosing the GET and that handles transient errors like RC=2033 if the intent is that the program remains running even when the queue is empty. In that case though, it's customary to set the timeout to 10 seconds or so. With 100ms timeout, the app as written would absolutely hammer the listener if it were modified to stay running.

Also, the exception handling does not show any code for printing the linked exception. JMS exceptions are multi-level data constructs in which the transport provider's native error code is in the linked part of the exception. If the error handling doesn't look at the linked exception it cannot even tell the difference between MQRC=2033 (no messages) versus MQRC=2035 (authorization error). One of these is transient and should be survived by the program, the other is always fatal. At the very least, the code should either print the linked exception or else print a message stating no linked exception was found.

So with regard to the loop and processing design, it's not possible to answer for values of "right" without knowing requirements. With regard to exception handling, definitely not right as no linked exception processing is present.

...and whether I need to commit the connection.

Depends. Is it OK to lose or duplicate messages? If so then transactions are not needed. Use of transacted sessions protects against loss of messages but not dupes. Use of XA 2-Phase Commit protects against both loss of messages and against dupes. The idea is to pick the class of service (generally referred to as "At most once," "At least once," or "Once and only once") that meets the business requirement and code accordingly.

Infinite for-loop is right way to receive messages all the times from the queue, is it right?

That's one way to do it. For high availability and high throughput, typically there are two or more instances of the application listening on the same queue. That way if one app server instance goes down (whether planned or unplanned) the other instance(s) continues to serve the queue. In general all of these instances listen on the queue with about a 10-second timeout.

Also customary is that the GET on the queue specifies MQGMO_FAIL_IF_QUIESCING which allows the QMgr to interrupt the application when the MQ Admin tries to shut the QMgr down. If this option is not specified, the only to shut the QMgr down is to ask it to forcibly break the outstanding connections and this should only be done as a last resort.

It's also possible to cause MQ to trigger the app to start when a message arrives on the queue. That's not typically done when the app runs on a JEE server but is very useful for stand=-alone apps.

Answer 2

I would go for a multi-threaded application where each thread does the following:

1) Connects to queue manager.

2) Create a consumer for a queue.

3) Setup a message listener to receive messages asynchronously. If this does not suit then go for synchronous message receive using the receive() method.

4) Do clean up when message consumption is done.

Advantage of this: Threads receiving messages from their respective queue and are not blocked for any reason.