When a queue manager sends out some information about itself, for example to advertise the creation of a new queue, the full and partial repository queue managers store the information for 30 days. To prevent this information from expiring, queue managers automatically resend all information about themselves after 27 days. If a partial repository sends a new request for information part way through the 30 day lifetime it sees an expiry time of the remaining period. When information expires, it is not immediately removed from the repository. Instead it is held for a grace period of 60 days. If no update is received within the grace period, the information is removed. The grace period allows for the fact that a queue manager may have been temporarily out of service at the expiry date. If a queue manager becomes disconnected from a cluster for more than 90 days, it stops being part of the cluster. However, if it reconnects to the network it will become part of the cluster again. Full repositories do not use information that has expired to satisfy new requests from other queue managers.
Similarly, when a queue manager sends a request for up-to-date information from a full repository, the request lasts for 30 days. After 27 days WebSphere MQ checks the request. If it has been referenced during the 27 days, it is remade automatically. If not, it is left to expire and is remade by the queue manager if it is needed again. This prevents a build up of requests for information from dormant queue managers.
Comments