| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Logical GET across queue managers |
« View previous topic :: View next topic » |
| Author |
Message
|
| mattb |
 Posted: Wed Jan 30, 2008 10:33 am Post subject: Logical GET across queue managers |
 |
|
Newbie
Joined: 15 Oct 2007
Posts: 8
|
Hi All
I have a newbie MQ clustering design question which I hope you can help with. Sorry the example is a bit long.
To a client posting a job, there should appear to be 2 queues: Q.JOBS.A and Q.JOBS.B
For load balancing we would have 1 gateway queue manager (GWQM) and 2 application queue managers (QM1 and QM2)
Each application queue manager would host 2 local queues : Q.JOBS.A and Q.JOBS.B
The gateway queue manager would use round robin load balancing to route the jobs to the local queues on the 2 application queue managers.
This achieves the goal of allowing the client to perform a put to a logical queue with the jobs being distributed to local queues on the application queue managers.
My question relates to the 'server side' processing the client jobs...
Assume I have 10 servers, SV1..SV10. I want these servers to process jobs on Q.JOBS.A before jobs on Q.JOBS.B.
Assume servers have been split with
SV1..SV5 connecting to QM1 Q.JOBS.A and Q.JOBS.B
SV6..SV10 connecting to QM2 Q.JOBS.A and Q.JOBS.B
If SV1..SV5 have completed all the jobs on QM1 Q.JOBS.A, I would like them to look for jobs on QM2 Q.JOBS.A before processing jobs on QM1 Q.JOBS.B or QM2 Q.JOBS.B
Is this possible ?
My understanding is that MQGETs can only be performed on 'physical' local queues, which would mean that SV1..SV5 could not connect to QM2 to look for jobs on Q.JOBS.A
Does MQ provide a mechanism / configuration which allows a server to perform a logical GET, where a job could come from Q.JOBS.A on either of the queue managers QM1 or QM2 ?
Thanks in advance,
Matt |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jan 30, 2008 10:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This kind of defeats the purpose of the cluster workload balancing.
In a basic scenario, QM1 and QM2 would have a 50/50 split of load. This means that apps reading from QM1 would empty the queue there at roughly the same point in time as apps reading from QM2 - assuming the logical workload processing is equivalent (i.e. one side doesn't have bigger messages or etc.)
So what you would tend to find is that say SV1 would connect, and process on QM1. It would find QM1 was empty, and then connect to QM2. Then it would find that QM2 was empty, and then go back to processing on QM1 to either pick up JOBS.B or retry JOBS.A.
You're correct in thinking that there's no mechanism in MQ to allow an app to "magically" change what qmgr it is connected to (and thus can GET from). You have to code a disconnect/reconnect yourself.
But there's not a good reason, in this case.
It's a better idea to scale up the jobs reading from QM1 based on workload, and scale up the jobs reading from QM2 based on workload - independant of each other. I.e.... have something that decides to start SV11, SV12, SV13... etc. if QM2 is backing up...
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
