|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Clustering work load problem |
« View previous topic :: View next topic » |
Author |
Message
|
venkatesh1976 |
Posted: Mon Nov 11, 2002 2:15 am Post subject: Clustering work load problem |
|
|
Apprentice
Joined: 11 Nov 2002 Posts: 26
|
We have a proble on MQ clustering :
There are 2 Queue Managers along with 2 instances of the same queues which are clustered.
We are sending message to one queue , after exceeding the max Depth,
it does not send the overflowing messages to the other queues.
We have a cluster sender chl and cluster receiver chl along with a default
cluster xmitq.
The errror code we get is 2053 which says we have exceeded the max depth, but accordingly the overflowing messages should be distributed. |
|
Back to top |
|
 |
2189 |
Posted: Mon Nov 11, 2002 9:19 am Post subject: |
|
|
Apprentice
Joined: 22 Oct 2002 Posts: 31
|
Cluster queue availability is not determined by queue depth. A sending qmgr will still see the queue as available even if it's full. The sending qmgr does not hold any information about the depth status of a cluster queue. The info it knows about can be seen by using the command DIS QCLUSTER(QNAME).
As the normal workload algorithm is to round robin between the queues you will have to code your program to detect a 2053 error in which case I understand you'd need to close the queue, open it again which would then select the 2nd queue instance and then put again.
Hope that makes some sense. _________________ 2189 errors make me  |
|
Back to top |
|
 |
leongor |
Posted: Tue Nov 12, 2002 7:57 am Post subject: |
|
|
 Master
Joined: 13 May 2002 Posts: 264 Location: Israel
|
I don't think that there is a good solution for this problem.
Maybe using high depth event to trigger some program that will disable the queue to put. _________________ Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
Back to top |
|
 |
mfeenstra |
Posted: Tue Nov 12, 2002 12:18 pm Post subject: |
|
|
 Novice
Joined: 03 Jul 2002 Posts: 12
|
The only solution to this problem is to design a cluster workload exit algorithm. The logic of the algorithm, could for example, switch to a different available destination if the target destination has queue full.
The default cluster workload balancing algorithm is very simple, and does not address this issue. _________________ Matt Feenstra
IBM Certified Specialist - MQSeries |
|
Back to top |
|
 |
oz1ccg |
Posted: Fri Nov 15, 2002 8:11 am Post subject: |
|
|
 Yatiri
Joined: 10 Feb 2002 Posts: 628 Location: Denmark
|
it's quite simple to write a clwl exit that creats a loop (all queues are full..).
a simple way out of this might be just write a small eventhandler, that receives the SYSTEM.ADMIN.PERFM.EVENT, and when receiving a Q_FULL event the SET PUT-INHIBIT, and when going below the low_water mark enable the queue again.
Doing it this way leaves IBM' clwl in charge, and don't create any loops....
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
|
|
|
|