Information on MQ Message Behavior

The following is general information on WebSphere MQ (aka MQSeries) message behavior during normal and abnormal message processing. The first thing to understand about MQ is that, it is not a database but a real-time messaging system. It was built on the following 2 principles:

  1. Once-only delivery of a message
  2. Assured delivery of a message (not guaranteed for legal reasons)

MQ supports 2 types of messaging models: point-to-point and Publish/Subscribe (Pub/Sub).

MQ messaging behavior when MQ is used as a point-to-point messaging system:

  1. Unconsumed non-persistent messages will remain on a queue regardless of what has happened to the application (i.e. crashes, normal disconnects, etc). If a queue manager is restarted then ALL non-persistent messages in a queue with attribute NPMCLASS equal to Normal are deleted. If the queue’s attribute NPMCLASS is equal to High then the messages are not deleted.
  2. Unconsumed persistent messages will remain on a queue regardless of what has happened to the application (i.e. crashes, normal disconnects, etc). If a queue manager is restarted then persistent messages survive a queue manager restart.

MQ messaging behavior when MQ is used as a Pub/Sub messaging system:

  1. For non-durable subscriptions, if a consumer disconnects or crashes or loses connectivity to the queue manager for any reason, then ALL published messages will NOT be saved / stored for that particular consumer (Other consumers are not affected). When the consumer reconnects, they will begin receiving messages ONLY from the point in time that they successfully reconnected. All previous pub/sub messages (during the disconnection period) will be discarded.
  2. For durable subscriptions, if a consumer disconnects or crashes or loses connectivity to the queue manager for any reason, then all published messages will be saved / stored for that particular consumer. When the consumer reconnects they will receive all outstanding messages for that particular topic. Of course, the biggest problem with durable subscriptions is ‘what if the consumer never reconnects?’ This means that messages would accumulate forever and fill-up the queue. MQ applications should only use durable subscriptions when the application will be reconnecting to the queue manager in a timely fashion.

Unit of Work (i.e. SYNCPOINT)

If any message is put on a queue under a Unit Of Work (UOW) then there are other MQ behaviors that must be considered.

  1. If an application issues an MQDISC or ends normally, with current uncommitted operations, an implied MQCMIT is executed by WebSphere MQ (i.e. all operations done under SYNCPOINT are committed).
  2. If an application crashes / abnormally ends then an implied MQBACK is executed by WebSphere MQ (i.e. all operations done under SYNCPOINT are backed-out).

Once the user understands how MQ behaves then they will understand what is happening to the application’s messages during normal and abnormal processing.

Regards,
Roger Lacroix
Capitalware Inc.

This entry was posted in IBM MQ, Programming.

Comments are closed.