| Author |
Message
|
| neutron |
 Posted: Mon May 23, 2011 8:07 pm Post subject: Cluster QM unable to receive proxy Subscriptions |
 |
|
Novice
Joined: 25 Aug 2008
Posts: 21
|
Cluster with 4 QMs.
QM A / B / C / D
QM A C D are FR
Clustering Queues works
Cluster Channels running
Cluster topics can be seem from all QMs (with all topics pub/scope set to 'all')
QM B (PR) and C(FR) has all proxysubscriptions from QM B and C. Does not have proxy Subscription of QM A. QM D (FR) has all proxy Subscription of QM A / B / C.
QM D is only a QM for FR purpose.
QM A only has subscription of itself. Does not have subscription from others QM.
----------------------------
1) I have refresh proxy subscription but QM A is still not updated
2) I have remove QM A from Cluster and rejoin it back, also not updated.
3) i have force one topic to set proxy subscription behavior to 'force', this does not get updated also.
Can someone help on how i can get QM A to refresh its subscriptions table to have all subscriptions from all other QM in the cluster? |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon May 23, 2011 11:03 pm Post subject: Re: Cluster QM unable to receive proxy Subscriptions |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| neutron wrote: |
| ...QM A C D are FR... |
Why? In a cluster of only four queue managers within the same cluster what possible reason do you have for three FRs? Which version of WMQ are you using?* Have all the queue managers established communication with all other queue managers, notwithstanding that you have stated this is so, i.e. do you see only channels to/from FR-to-FR and PR-to-FR?
* V7.0.x implied as you are using clustering
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| neutron |
| Posted: Tue May 24, 2011 12:34 am Post subject: |
|
|
Novice
Joined: 25 Aug 2008
Posts: 21
|
Why? In a cluster of only four queue managers within the same cluster what possible reason do you have for three FRs?
>> Was 2, i upgrade QM A to FR to try my luck to see if that helps to send the proxy subscription info over as i see QM D has all the proxy subscription.
Which version of WMQ are you using?*
>> 7.0.1.5
Have all the queue managers established communication with all other queue managers, notwithstanding that you have stated this is so, i.e. do you see only channels to/from FR-to-FR and PR-to-FR?
FR to FR all running
PR to FR all running
Case was logged and its appeared to be a very funny symptom. I trying to get some expert advice from here to see if there is a "special" way that i can somehow trigger a "refresh"
I am thinking if i do a cold start, will it help? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue May 24, 2011 1:03 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
As it is such a small cluster I advocate tearing it down and starting again, with only two FRs, and ensuring that all requisite channels are running before proceeding to add subs. Bear in mind that in a pub/sub cluster all queue managers will define channels to each other immediately, which is different to a 'vanilla' cluster in which queue managers will define channels only when needed. I'm trying to remember (I have no access to my notes at the moment) whether proxy subs apply within the context of pub/sub clusters, so you may be looking for something that isn't there in a non-hierarchical topology.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| neutron |
| Posted: Tue May 24, 2011 10:24 am Post subject: |
|
|
Novice
Joined: 25 Aug 2008
Posts: 21
|
As it is such a small cluster I advocate tearing it down and starting again, with only two FRs, and ensuring that all requisite channels are running before proceeding to add subs.
>> i have down it to 2 FR.
Things i have done:
1) Cold Start the QM
2) tried also recreate the QM again
3) from the other QM, i delete all SUB and then recreate them again. Still QM A is not having the info.
Highly suspect QM A has some missing thing or instruction to QM may be stuck somewhere. As QM A is already a new QM.
Bear in mind that in a pub/sub cluster all queue managers will define channels to each other immediately, which is different to a 'vanilla' cluster in which queue managers will define channels only when needed.
>> Does this mean i have create clussdr channels to all the other QMs from each QM? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue May 24, 2011 11:02 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| neutron wrote: |
| >> Does this mean i have create clussdr channels to all the other QMs from each QM? |
No, I do not mean that. The creation of a pub/sub cluster is no different to a non-pub/sub cluster. The point I was trying to make was that you should be able to see manually defined CLUSSDR channels running FR-to-FR and manually defined CLUSSDR channels running PR-to-FR when you build the 'basic' cluster; unless you have then defined cluster objects in the PRs and either/both PRs need to reference those objects, you will not see PR-to-PR channels. Once you introduce pub/sub objects into the cluster then you will observe auto-defined PR-to-PR CLUSSDR channels running. Is the issue that you can't 'see' the sub(s) in one queue manager, and expect to see it, or is it that no message is being delivered to that particular subscriber?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| neutron |
| Posted: Wed May 25, 2011 12:48 am Post subject: |
|
|
Novice
Joined: 25 Aug 2008
Posts: 21
|
Is the issue that you can't 'see' the sub(s) in one queue manager, and expect to see it, or is it that no message is being delivered to that particular subscriber?
We have subscribers in all QM A, B and C all subscribing to the same topic. And we have publishers in QM A, B and C to publish to the topic.
When i publish from A, only subscrbr from A can get the message.
When i publish from either B or C, both B and C subscrbr will receive the message.
I have another set of QM A, B and C (same setup) in another network segment (DEVELOPMENT Env).
When i publish from either A, B or C, all A, B and C subscrbr will recvd the message.
Thanks a lot in advance for your advices. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 25, 2011 12:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| neutron wrote: |
When i publish from A, only subscrbr from A can get the message.
When i publish from either B or C, both B and C subscrbr will receive the message.
I have another set of QM A, B and C (same setup) in another network segment (DEVELOPMENT Env).
When i publish from either A, B or C, all A, B and C subscrbr will recvd the message. |
Forensically compare every object, attribute, and build parameter between the 'working' and 'non-working' environments; pay particular attention to how security may be affecting you. Use the MS03 SupportPac to dump the objects of each queue manager and compare the files of each and its analogue. Apart from object names (possibly) and CONNAME parameters there should be no differences. If there are, correct them and try again.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| neutron |
| Posted: Wed May 25, 2011 3:08 am Post subject: |
|
|
Novice
Joined: 25 Aug 2008
Posts: 21
|
i will be doing the comparison. But to note, the working env is in 7.0.1.4 and the non working is in 7.0.1.5
there is a number of patches for 7.0.1.5 for JMS related issue am i right? |
|
| Back to top |
|
|
| neutron |
| Posted: Fri May 27, 2011 2:56 am Post subject: |
|
|
Novice
Joined: 25 Aug 2008
Posts: 21
|
Great news. I have found out the area of problem and the pub/sub is working now. As these 3 QMs Definition was taken from the existing MQ6 Hierarchical Broker Setup machine. Although we have removed the SDR/RCVR CHN used by the broker. We missed out removing the Transmission Queues.
I found out that the old transmission queues from all other QMs to QM A were holding messages. I went on to create the SDR/RCVR channel for all QMs to QM A. And there, I managed to get all the proxy subscriptions at QM A. |
|
| Back to top |
|
|
|
|
