| Author |
Message
|
| Inforz |
 Posted: Thu May 26, 2011 6:17 am Post subject: Some cluster doubts |
 |
|
Centurion
Joined: 15 Apr 2011
Posts: 139
Location: Chennai, India
|
Hi there,
few doubts on clustering. There is a cluster setup with two FRs QM1 and QM2. Now I add a partial repository QM3 with a clussdr and clusrcvr to QM1. And I add a partial repository QM4 with a clussdr and clusrcvr to QM2.
# 1Now I issue a dis chs(*) on QM3 and see a clussdr chl pointing to QM2 in retrying state. What does this imply
# 2 If the QM1 goes down and I put a test msg as follows in QM4:
amqsput QM3.Q1 QM4 and a test msg.
QM3.Q1 is a clusq present in QM3. Will this cmd deliver the msg successfully to that queue, since QM1 is down and QM3 has direct contact only to QM1. If so how?
Thanks, |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 26, 2011 6:24 am Post subject: Re: Some cluster doubts |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Inforz wrote: |
| # 1Now I issue a dis chs(*) on QM3 and see a clussdr chl pointing to QM2 in retrying state. What does this imply |
That there's something (probably network related) preventing the channel working & you need to fix it.
| Inforz wrote: |
| QM3.Q1 is a clusq present in QM3. Will this cmd deliver the msg successfully to that queue, since QM1 is down and QM3 has direct contact only to QM1. If so how? |
Yes it will deliver it and yes it does have a direct connection to other queue managers. As you've noticied in your point 1.
If you read the clustering manaual you'll notice that all the queue managers in a cluster directly connect one to the other for message transmission. It's not the case (though many people believe it to be) that all messages flow through the FRs. They do not. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 26, 2011 6:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ Clusters always connect directly to the destination queue manager.
They do not connect to an FR and then the FR forwards messages. Messages always go on a direct route between the relevant two queue managers.
MQ Clustering does not provide any different failure or retry scenarios when the destination queue manager is unavailable than exist when using normal sender/receiver channels. The only thing that is different is the name of the XMITQ in use. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 26, 2011 6:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| MQ Clusters always connect directly to the destination queue manager. |
MQ cluster queue managers always connect directly to the destination queue manager.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 26, 2011 6:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| mqjeff wrote: |
| MQ Clusters always connect directly to the destination queue manager. |
MQ cluster queue managers always connect directly to the destination queue manager. |
Yes, fine. "MQ Clusters tend over time to form fully connected networks between individual queue managers, but MQ clusters themselves do not exist as addressable or separate objects and you always connect to a specific queue manager and not to the cluster as a whole". |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 26, 2011 7:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Sorry, Jeff. I hadn't intended to offend.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 26, 2011 8:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Sorry, Jeff. I hadn't intended to offend. |
No offense.  |
|
| Back to top |
|
|
| Inforz |
| Posted: Fri May 27, 2011 1:01 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2011
Posts: 139
Location: Chennai, India
|
Ok thanks guys, if you dont mind i shall continue with few general MQ questions in this topic.
What exactly is the use of spcifying a xmitq in the chl defn? We already have a xmitq defined in the remote queue right?
And what if different xmitq's are specified in the remote queue and chl defn? which xmitq queue would be used in which cases?
To my knowledge SYSTEM.CLUSTER.TRANSMIT.QUEUE would be used as xmitq for a clussdr chl. What if this q is deleted mistakenly after chl creation, and if a msg comes in to be sent thru the chl, what happens?
Thanks, |
|
| Back to top |
|
|
| Inforz |
| Posted: Fri May 27, 2011 3:17 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2011
Posts: 139
Location: Chennai, India
|
jus one more to add..
my clussdr from a PR to FR shows the conname just as i defined and not resolving into its ip although the chl is in running state. But during a dis chs(*) the other clusrcvr chls (that get created on the fly) are showing the resolved ips in the conname. will this create a problem? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 27, 2011 6:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Inforz wrote: |
| What exactly is the use of spcifying a xmitq in the chl defn? |
Do you even think before asking these questions? Think a little about what the channel does (i.e. moves messages from one queue manager to another) and wonder to yourself how the channel would know where to get the message from without a queue name.
| Inforz wrote: |
| We already have a xmitq defined in the remote queue right? |
Wrong. The xmitq is optional in a remote queue definition.
| Inforz wrote: |
| And what if different xmitq's are specified in the remote queue and chl defn? which xmitq queue would be used in which cases? |
The remote queue would use that xmitq in it's definition, the channel would use the xmitq in it's definition. Obviously.
| Inforz wrote: |
| To my knowledge SYSTEM.CLUSTER.TRANSMIT.QUEUE would be used as xmitq for a clussdr chl. What if this q is deleted mistakenly after chl creation, and if a msg comes in to be sent thru the chl, what happens? |
Nothing good happens. Just like if you delete any SYSTEM objects.
Re-read the Intercommunication manual & the primer. You seem to have some basic failures of understanding.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 27, 2011 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Inforz wrote: |
| will this create a problem? |
Why would it? What the difference between the ip you've typed and the resolved one? What's the functional difference?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
