| Author |
Message
|
| schandolu |
 Posted: Fri Jan 03, 2014 6:44 am Post subject: Does Topics in MQ Support Load Balancing? |
 |
|
Newbie
Joined: 26 Dec 2013
Posts: 9
|
Hi ,
i am new to WMB.As per my understanding from EMS/JMS,Topics does'nt support LOAD Balancing(i.e we cannot scale the instances at subscriber side) if multiple consumers are subscribing to it.
If we want to configure load balancing we will use queues.
Please let me know wheather this is the same case in IBM MQ?
Thanks,
Siv
 |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jan 03, 2014 7:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Every subscriber gets a copy of every publication.
How is that not scalable? |
|
| Back to top |
|
|
| schandolu |
| Posted: Fri Jan 03, 2014 8:55 am Post subject: |
|
|
Newbie
Joined: 26 Dec 2013
Posts: 9
|
| Can the load be distributed if there are any multiple instances of same adapter service is subscribed to the source topic. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 03, 2014 9:03 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You are asking if a given message can be given to some subscribers but not all, on a load balancing basis. Essentially no.
However if you create administrative subscription(s) which direct the messages to one or more queues, then you can have more than one listener on some or all of those queues if you like.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 03, 2014 9:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
You are asking if a given message can be given to some subscribers but not all, on a load balancing basis. Essentially no.
However if you create administrative subscription(s) which direct the messages to one or more queues, then you can have more than one listener on some or all of those queues if you like. |
Which means essentially yes, but you need to shape your subscription to dispatch the topic to a specified queue... using all the aliasing the cluster allows you too... It gets really tricky if you want the consumer to be a topic consumer but vastly easier if the consumer is a queue consumer.
You'll still see the Destination on the messages being a topic destination...
The truth is not some subscribers vs others, but essentially multiple instances of the same subscriber on different boxes.... Note that the subscription should only be done once across all instances of subscribers. Hence much easier to do with an admin type subscription...
In order to set up the topic consumption correctly you might have to create the subscription once per consumption instance and delete it administratively as a duplicate... on the producer qmgr... (not tried) having the consumer being a queue consumer however works fine...(tried)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sridhsri |
| Posted: Mon Jan 06, 2014 9:13 am Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
I agree that explicitly creating subscriptions in MQ (with destination as a queue) is probably the best way to do it.
However, I think it is possible without doing that as well. If more than one subscribers have the same "client id" then all of subscribers will not receive a copy of the message (only one of them will). For this to work I think the subscribers have to be durable. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jan 07, 2014 2:40 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
There are MSGDLV options, but I am not sure your statement is correct about client id, but then I have no idea what this is.
I assume it's something to do with MQSO_FIXED_USERID vs MQSO_ANY_USERID
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Tue Jan 07, 2014 7:48 am Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
The notion of a client id is part of the JMS specification. It is not MQ specific. Every durable subscriber has a unique client id associated with it (if none is set by the user, then one is automatically generated).
If more than one subscribers share this client id, then only one of them will receive a subscription. We use this technique today. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jan 07, 2014 8:36 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Well it doesn't work that way with administrative subs. I just defined two subs from mqm user with the same dest queue and when I published a message - that queue received two copies.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 07, 2014 8:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| Well it doesn't work that way with administrative subs. I just defined two subs from mqm user with the same dest queue and when I published a message - that queue received two copies. |
You can't change the SUBID of an administrative subscription. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jan 07, 2014 8:45 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Sub id, as opposed to Sub User id....
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Tue Jan 07, 2014 9:46 am Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
mqjeff is correct.
For this to work, you must use managed subscriptions. In the Java application you will supply the "client id". |
|
| Back to top |
|
|
|
|
