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.