| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQClustering problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| priyasl |
 Posted: Mon Nov 18, 2002 12:02 am Post subject: MQClustering problem |
 |
|
Newbie
Joined: 17 Nov 2002
Posts: 2
|
I have three queuemanagers in a cluster QM1, QM2, QM3
QM1 and QM2 have full repositories and cluster channels between them.
QM1 and QM3 have a clustered queue CQ and there is a cluster sender/ cluster receiver channel between QM1 and QM3.
CQ queue in each Queue manager has a maxdepth of 5.
From the client (java), when i try to put messages into the QM2, it routes the messages to QM1, but after the 5 messages are put into CQ of QM1, the messages thereafter are put into the dead letter queue of QM1 instead of being routed to CQ of QM3.
Pls clarify at the earliest. |
|
| Back to top |
|
 |
| oz1ccg |
| Posted: Mon Nov 18, 2002 2:34 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
If you want the workload balancing to work, the application have to put the message to a "front-end" mq, in your case it would work if the application was conneted to QM2.
The simple workload balancing code priotize the local qmgr highest, and don't try to send the message to another qmgr, even if the queue is full, it only sends the messages away if the queue is put-disabled.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 20, 2002 9:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Sounds to me like this is a Bind_On_Open issue.
CQ lives on QM1 and QM3, each with a max depth of 5 right? And your putting app connected to QM2, right?
If it did a Bind On Open, by chance the algorithim picked CQ on QM1, and from that point forward, all your messages put under that handle would go to CQ on QM1. When the queue filled up, they do to the DLQ, because the Bind on Open Option said you want all your message to only go to the first instance of CQ it gets. In effect, it no longer sees CQ on QM3.
Check for this option on your MQOPEN call. You want to use MQOO_BIND_NOT_FIXED. This way the messages will go back and forth between QM1 and QM3, if the putting app is connected to QM2.
If you do not specify either MQOO_BIND_ON_OPEN or MQOO_BIND_NOT_FIXED, the default option is MQOO_BIND_AS_Q_DEF. Using MQOO_BIND_AS_Q_DEF causes the binding that is used for the queue handle to be taken from the DefBind queue attribute.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| nimconsult |
| Posted: Wed Nov 20, 2002 11:14 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
I agree with your comment, Peter.
I have one question:
if I open a queue with MQOO_BIND_AS_Q_DEF, but the two definitions of CQ have a diferent default bind option (say CQ on QM1 has default BIND_ON_OPEN and CQ on QM2 has default BIND_NOT_FIXED), which bind option will be picked up? 
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 21, 2002 5:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Well, if the algorithem picked the Bind on Open one, then it would stick with that one for all the messages.
If it picked the Bind Not Fixed, then message 1 would go there, message 2 would go to the Bin On Open one, and message three would go??????
Something to test later today!!!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Dec 02, 2002 7:22 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Let's make this thread alive again....
I've just tried the setup... and it work as I thourgh  , what really happens is Cluster workload alogorithm decides on the put where to put the message... QM3 or QM1. The sending qmgr (QM2) don't know anything about the full queue.... There are room for enhancements in that area.
It seems to me that the sending qmgr slows down when messages is placed in the target qmgr DLQ. until I changed the put inhibit on eg. QM3s queue QM2 is sending messages to the DLQ even when there are room in QM1  When teh target queue on QM3 is set to put-inhibit the messages is very fast send to QM1 from QM2. That was also what I expected it to do (after developing some CLWL exits.)
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| 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
|
|
|
|
