7.5 Cluster Queues on Full Repository Question

[Tim Zielke]

Hello,

I noticed something odd when working with my Sandbox servers and validating 7.5.0.2 and 7.5.0.3. We have two sandbox servers. One is a SLES 11 server. The other is a Solaris 10 server. Each has one queue manager which is a full repository and participate in one cluster called SBOX.

I was playing around with clustering on the Linux one, and I noticed the following:

If I created a cluster queue in SBOX on the Solaris server, and then tried to PUT to the queue from the Linux server, I would get a 2085. The Solaris full repository was not communicating to the Linux full repository that the new cluster queue existed. If I then did a REFRESH CLUSTER on the Linux queue manager, the Linux queue manager would get the update and I could successfully PUT to the new queue.

When I then changed the Linux queue manager from being a full to a partial repository, this behavior did not exist. I created a cluster queue in SBOX on the Solaris queue manager, and the Linux queue manager knew right away about the new queue. The first PUT to the cluster queue on the Linux server was successful.

I then changed the Linux queue manager back to a full repository, created a new cluster queue on the Solaris queue manager, and again I get the 2085 behavior when doing the PUT on the Linux server.

This looks like a bug to me. But we would never see this in practice as we use our full repositories solely to manage clustering, and do not put any cluster queues or application work directly on them. I just happened to run across it because of our Sandbox set up. But then it made me wonder, is it ok to put cluster queues on full repositories? I am thinking yes and the manual seems to imply that is ok.

Does anyone think this is bad configuration on my part?

Or does this look like an MQ clustering bug?

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

[Potkay, Peter M (CTO Architecture + Engineering)]

What you are attempting should work.

Does the reverse (both are FRs, create new cluster q on Linux FR, try and put to it from Solaris FR) show the same problem?

It's very odd that simply changing it from a FR to a PR allows it to find the queue.

Both FRs should show all clustered queues. If you create a new clustered queue on the Linux FR, does it show up when you display all queues on the Solaris FR? If you create a new clustered queue on the Solaris FR, does it show up when you display all queues on the Linux FR? This is before you attempt to MQOPEN/MQPUT1 to it - just a plain and simple display. Don't use MQExplorer to test what each FR shows, use runmqsc directly on each server.

Both are at 7.5.0.3?



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Monday, June 23, 2014 3:51 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: 7.5 Cluster Queues on Full Repository Question

Hello,

I noticed something odd when working with my Sandbox servers and validating 7.5.0.2 and 7.5.0.3. We have two sandbox servers. One is a SLES 11 server. The other is a Solaris 10 server. Each has one queue manager which is a full repository and participate in one cluster called SBOX.

I was playing around with clustering on the Linux one, and I noticed the following:

If I created a cluster queue in SBOX on the Solaris server, and then tried to PUT to the queue from the Linux server, I would get a 2085. The Solaris full repository was not communicating to the Linux full repository that the new cluster queue existed. If I then did a REFRESH CLUSTER on the Linux queue manager, the Linux queue manager would get the update and I could successfully PUT to the new queue.

When I then changed the Linux queue manager from being a full to a partial repository, this behavior did not exist. I created a cluster queue in SBOX on the Solaris queue manager, and the Linux queue manager knew right away about the new queue. The first PUT to the cluster queue on the Linux server was successful.

I then changed the Linux queue manager back to a full repository, created a new cluster queue on the Solaris queue manager, and again I get the 2085 behavior when doing the PUT on the Linux server.

This looks like a bug to me. But we would never see this in practice as we use our full repositories solely to manage clustering, and do not put any cluster queues or application work directly on them. I just happened to run across it because of our Sandbox set up. But then it made me wonder, is it ok to put cluster queues on full repositories? I am thinking yes and the manual seems to imply that is ok.

Does anyone think this is bad configuration on my part?

Or does this look like an MQ clustering bug?

Thanks,
Tim

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

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

[Tim Zielke]

After some more investigation, it looks like I had a gotten the Solaris full repository into a bad cluster situation. Last year we moved our Linux Sandbox server to another Linux server. This resulted in a new Linux server and new queue manager. In the process, it looks like I had deleted the CLUSSDR channel from the Solaris queue manager to the old Linux queue manager, but I never created a CLUSSDR to the new Linux queue manager. So this Solaris queue manager had no defined CLUSSDR channel. Anyway, I got that sorted out, and now things are working fine. User error :-)

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Monday, June 23, 2014 4:41 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: 7.5 Cluster Queues on Full Repository Question

What you are attempting should work.

Does the reverse (both are FRs, create new cluster q on Linux FR, try and put to it from Solaris FR) show the same problem?

It's very odd that simply changing it from a FR to a PR allows it to find the queue.

Both FRs should show all clustered queues. If you create a new clustered queue on the Linux FR, does it show up when you display all queues on the Solaris FR? If you create a new clustered queue on the Solaris FR, does it show up when you display all queues on the Linux FR? This is before you attempt to MQOPEN/MQPUT1 to it - just a plain and simple display. Don't use MQExplorer to test what each FR shows, use runmqsc directly on each server.

Both are at 7.5.0.3?



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Monday, June 23, 2014 3:51 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: 7.5 Cluster Queues on Full Repository Question

Hello,

I noticed something odd when working with my Sandbox servers and validating 7.5.0.2 and 7.5.0.3. We have two sandbox servers. One is a SLES 11 server. The other is a Solaris 10 server. Each has one queue manager which is a full repository and participate in one cluster called SBOX.

I was playing around with clustering on the Linux one, and I noticed the following:

If I created a cluster queue in SBOX on the Solaris server, and then tried to PUT to the queue from the Linux server, I would get a 2085. The Solaris full repository was not communicating to the Linux full repository that the new cluster queue existed. If I then did a REFRESH CLUSTER on the Linux queue manager, the Linux queue manager would get the update and I could successfully PUT to the new queue.

When I then changed the Linux queue manager from being a full to a partial repository, this behavior did not exist. I created a cluster queue in SBOX on the Solaris queue manager, and the Linux queue manager knew right away about the new queue. The first PUT to the cluster queue on the Linux server was successful.

I then changed the Linux queue manager back to a full repository, created a new cluster queue on the Solaris queue manager, and again I get the 2085 behavior when doing the PUT on the Linux server.

This looks like a bug to me. But we would never see this in practice as we use our full repositories solely to manage clustering, and do not put any cluster queues or application work directly on them. I just happened to run across it because of our Sandbox set up. But then it made me wonder, is it ok to put cluster queues on full repositories? I am thinking yes and the manual seems to imply that is ok.

Does anyone think this is bad configuration on my part?

Or does this look like an MQ clustering bug?

Thanks,
Tim

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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

[Coombs, Lawrence]

I have been putting cluster queues on my FRs for years without any issues.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Monday, June 23, 2014 2:51 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: 7.5 Cluster Queues on Full Repository Question

Hello,

I noticed something odd when working with my Sandbox servers and validating 7.5.0.2 and 7.5.0.3. We have two sandbox servers. One is a SLES 11 server. The other is a Solaris 10 server. Each has one queue manager which is a full repository and participate in one cluster called SBOX.

I was playing around with clustering on the Linux one, and I noticed the following:

If I created a cluster queue in SBOX on the Solaris server, and then tried to PUT to the queue from the Linux server, I would get a 2085. The Solaris full repository was not communicating to the Linux full repository that the new cluster queue existed. If I then did a REFRESH CLUSTER on the Linux queue manager, the Linux queue manager would get the update and I could successfully PUT to the new queue.

When I then changed the Linux queue manager from being a full to a partial repository, this behavior did not exist. I created a cluster queue in SBOX on the Solaris queue manager, and the Linux queue manager knew right away about the new queue. The first PUT to the cluster queue on the Linux server was successful.

I then changed the Linux queue manager back to a full repository, created a new cluster queue on the Solaris queue manager, and again I get the 2085 behavior when doing the PUT on the Linux server.

This looks like a bug to me. But we would never see this in practice as we use our full repositories solely to manage clustering, and do not put any cluster queues or application work directly on them. I just happened to run across it because of our Sandbox set up. But then it made me wonder, is it ok to put cluster queues on full repositories? I am thinking yes and the manual seems to imply that is ok.

Does anyone think this is bad configuration on my part?

Or does this look like an MQ clustering bug?

Thanks,
Tim

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

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