Tim Zielke
2014-10-03 13:42:30 UTC
Hello,
I will probably open a PMR on this clustering behavior I am encountering, but I was curious if anyone on the LISTSERV has any insight to what I am seeing.
We have a qmgr/cluster set up like the following:
(QMGR1 on Server1 in CLUS1) -> (QMGR2 on Server2 in CLUS1 and CLUS2) -> (QMGR3 on Server3 in CLUS2)
QMGR1 can not be in CLUS2 and QMGR3 can not be in CLUS1 due to network rules.
Apps on Server1 have a requirement where they need to be able to PUT to a clustered queue Q1 in CLUS2 on QMGR3.
We have accomplished that by setting up the following:
1. A qalias for Q1 that is hosted on QMGR2 and is in CLUS1.
2. A local queue of Q1 on QMGR3 that is in CLUS2.
When an application PUTs to Q1 on QMGR1, it is sent to QMGR2 because of its qalias for Q1 in CLUS1. When the message gets to QMGR2, the queue manager sees the queue exists on QMGR3 in CLUS2, and sends the message to QMGR3.
However, when we review our queue manager error logs, we see reports like the following on QMGR1.
10/02/2014 11:24:36 PM - Process(13507.1) User(mqm) Program(amqrrmfa)
Host(Server1) Installation(Installation1)
VRMF(7.5.0.2) QMgr(QMGR1)
AMQ9456: Update not received for queue Q1, queue manager
QMGR2 from full repository for cluster CLUS1.
EXPLANATION:
The repository manager detected a cluster queue that had been used sometime in
the last 30 days for which updated information should have been sent from a
full repository. However, this has not occurred.
The repository manager will keep the information about this queue for a further
60 days from when the error first occurred.
ACTION:
If the queue is still required, check that:
1) The cluster channels to and from the full repository and the queue manager
that hosts the queue, are able to run.
2) The repository managers running on these queue managers have not ended
abnormally.
This looks like a potential clustering issue to me, but would this be expected behavior for this cluster set up? I would assume the full repositories on CLUS1 would be publishing information for the clustered qalias Q1 to QMGR1. Also those action items 1 and 2 in the AMQ9456 check out fine for QMGR1, QMGR2, and the FRs.
Please let me know if anyone has seen this behavior, or has any insight to what we are seeing.
Thanks,
Tim
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
I will probably open a PMR on this clustering behavior I am encountering, but I was curious if anyone on the LISTSERV has any insight to what I am seeing.
We have a qmgr/cluster set up like the following:
(QMGR1 on Server1 in CLUS1) -> (QMGR2 on Server2 in CLUS1 and CLUS2) -> (QMGR3 on Server3 in CLUS2)
QMGR1 can not be in CLUS2 and QMGR3 can not be in CLUS1 due to network rules.
Apps on Server1 have a requirement where they need to be able to PUT to a clustered queue Q1 in CLUS2 on QMGR3.
We have accomplished that by setting up the following:
1. A qalias for Q1 that is hosted on QMGR2 and is in CLUS1.
2. A local queue of Q1 on QMGR3 that is in CLUS2.
When an application PUTs to Q1 on QMGR1, it is sent to QMGR2 because of its qalias for Q1 in CLUS1. When the message gets to QMGR2, the queue manager sees the queue exists on QMGR3 in CLUS2, and sends the message to QMGR3.
However, when we review our queue manager error logs, we see reports like the following on QMGR1.
10/02/2014 11:24:36 PM - Process(13507.1) User(mqm) Program(amqrrmfa)
Host(Server1) Installation(Installation1)
VRMF(7.5.0.2) QMgr(QMGR1)
AMQ9456: Update not received for queue Q1, queue manager
QMGR2 from full repository for cluster CLUS1.
EXPLANATION:
The repository manager detected a cluster queue that had been used sometime in
the last 30 days for which updated information should have been sent from a
full repository. However, this has not occurred.
The repository manager will keep the information about this queue for a further
60 days from when the error first occurred.
ACTION:
If the queue is still required, check that:
1) The cluster channels to and from the full repository and the queue manager
that hosts the queue, are able to run.
2) The repository managers running on these queue managers have not ended
abnormally.
This looks like a potential clustering issue to me, but would this be expected behavior for this cluster set up? I would assume the full repositories on CLUS1 would be publishing information for the clustered qalias Q1 to QMGR1. Also those action items 1 and 2 in the AMQ9456 check out fine for QMGR1, QMGR2, and the FRs.
Please let me know if anyone has seen this behavior, or has any insight to what we are seeing.
Thanks,
Tim
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html