| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| cluster question |
« View previous topic :: View next topic » |
| Author |
Message
|
| happyj |
 Posted: Fri Jul 29, 2005 2:24 am Post subject: cluster question |
 |
|
Voyager
Joined: 07 Feb 2005
Posts: 87
|
MQ 5.3 CSD09
I have 2 Queue Managers in a cluster QM1 and QM2 and both have a local queue MY.QUEUE
which is shared in the cluster.
I am testing this by putting messages onto queue MY.QUEUE from another queue manager also
in the cluster with default bind not fixed and the messages are evenly distributed between the two queues.
If QM1 is stopped with endmqm without removing the queue from the cluster, the first message seems to
still be sent to QM1 (please correct if this is not right) and all subsequent messages are sent to QM2.
The message is not lost as if I restart QM1 the first message will be on MY.QUEUE on QM1.
My questions are:
Where is the first message? It is not on the SYSTEM.CLUSTER.TRANSMIT.QUEUE on the sending QM
Is there a way that all the messages can be sent to QM2 when QM1 is not running so to avoid a message being stranded on QM1?
many thanks |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Fri Jul 29, 2005 2:35 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The first msg is in an indoubt transaction on the CLUSSDR channel to QM1. You can see this in the runmqsc command DIS CHS(CHLNAME) on the qmgr where you are putting the msg. The reason that the channel goes indoubt is that the CLUSSDR does not discover that the CLUSRCVR on QM1 has ended until it gets the msg from the cluster xmitq, ends the channel batch, prepares the transaction, and sends the msg. It is then too late to backout the msg and send it to an alternative destination.
Try setting the channel attribute BATCHHB - look up how to use it in the Command Reference manual. Briefly, the attribute causes a data flow to be sent to the partner qmgr before the batch is committed. If no reply is received, the batch is backed out and the channel ends abnormally. On a cluster channel, this causes the msgs on the cluster xmitq for the channel to be reallocated to alternative destinations in the cluster, if any are available. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Jul 29, 2005 2:59 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
If this is a planned shutdown, you should first suspend the qmgr:
| Code: |
| SUSPEND QMGR CLUSTER(SALES) |
_________________
-wayne |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jul 29, 2005 3:14 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
Although this is not my thread, a question related to the BATCHHB.
the manual reads:
| Quote: |
If the sending channel has had a communication from the receiving channel within the batch heartbeat interval, the receiving channel is assumed to be still active, otherwise a ’heartbeat’ is sent to the receiving channel to check.
| |
|
now, what is a communication? is sending a message a communication or is it just commits and heartbeats?
if i have a channel with batchint0, i will do commits very fast (when xmitq is empty or batsz is full), so - if using batchhb, i will need a very small value (assuming sending a message is a "communication"), or am i wrong?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| happyj |
| Posted: Fri Jul 29, 2005 7:22 am Post subject: |
|
|
Voyager
Joined: 07 Feb 2005
Posts: 87
|
The channel on the sending QMgr ( auto defined CLUSSDR ) had
a status of retrying and indoubt YES. The errors in AMQERR01.LOG were
about the channel being in RETRYING.
I will investigate setting BATCHHB on the channel. I assume this needs to be on the manually defined CLUSSDR to the Full repos QMgr. For this to be effective it will have to be a low value, maybe 1 ? Any consequences of this ?
This situation didn't occur if i first altered the queue cluster property to ' ' before endmqm, which I can do with a controlled shutdown. I expect that suspend qmgr will have the same effect. What i'm trying to do is test
for situations where a controlled shutdown is not possible.
thanks again for all your help. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
