Checking for expired messages

Explanation of when MQe checks for expired messages

A message is checked for expiry when:
It is added to a queue
Expiry can occur when a message is added from the local API, pulled down via a Home Server Queue, or pushed to a queue.
It is removed from a queue
Expiry can occur when a message can be removed from the local API, or when a message is pulled remotely.
A queue is activated
When a queue is activated, a reference to the queue is created in memory. Any message that has expired is removed. The state of the message is irrelevant to this operation.
A queue is deleted
If an admin message arrives to delete a queue, the queue must be empty first. Therefore, before this check is done, any expired messages are removed from the queue. The state of the message is irrelevant to this operation.
A queue is checked for size
If an admin message arrives to inquire on the size of a queue, the queue is first purged of admin messages.
You can add a queue rule to notify you when messages expire. However, in a certain situation between two queue managers, a message may seem to expire twice. This is not because the message has been duplicated, but is outlined in the following paragraph.

Assume that an asynchronous queue has a message on it due to expire at 10:00 1st Jan 2005. All messages on such queues are transmitted using a 2 stage process. This process is equivalent to a putMessage and confirmPutMessage pair of operations. Suppose that the first transmission stage occurs at 09:55. A reference to the message appears on the remote queue manager. However, it is not yet available to an application on that queue manager. Then, if the network fails until 10:05, the expiry time of the message is missed. Therefore, the message expires on the remote queue and the queue expiry rule gets fired. Also, in due course, the queue expiry rule gets fired on the destination queue manager.


Terms of use | WebSphere software

(c) Copyright IBM Corporation 2004, 2005. All rights reserved.