|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Can a Pure JMS Client Access QM Cluster? |
« View previous topic :: View next topic » |
Author |
Message
|
yalmasri |
Posted: Wed Nov 06, 2013 7:23 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
mqjeff wrote: |
It also doesn't make sense to say "connect to an MQ Cluster". |
Referencing the link I sent in the original post, in order to send to a clustered queue from outside the cluster, you have to connect to a gateway queue manager within the cluster, this is effectively connecting to the cluster. |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Nov 06, 2013 7:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
yalmasri wrote: |
mqjeff wrote: |
It also doesn't make sense to say "connect to an MQ Cluster". |
Referencing the link I sent in the original post, in order to send to a clustered queue from outside the cluster, you have to connect to a gateway queue manager within the cluster, this is effectively connecting to the cluster. |
No, no it's not.
You only ever connect to a queue manager, using a SVRCONN/CLNTCONN or bindings connection.
There is no notion of connecting to a cluster. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Nov 06, 2013 8:34 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
yalmasri wrote: |
this is effectively connecting to the cluster. |
No it isn't, it's not effectively anything, it's actually something.
You're going to get very confused and make this a lot harder than it needs to be for you if you cling to the concept of a cluster being a technological entity you can connect to when in fact it's a philosophical entity used to describe a workload pattern.
And to correct you further, post WMQv7 (as has been pointed out more than once) you don't need to connect to a gateway queue manager, just to one of the participating queue managers. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
yalmasri |
Posted: Wed Nov 06, 2013 11:36 pm Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
You were all right guys! Using the setup I have, I created a sample, configured it properly, tested it, and the results were as you mentioned; sending messages from a client without using a queue manager to a particular queue in a cluster will forward them to all other queues with the same name in the cluster. This applies to both client and bindings (in case you're sending from local machine).
Thanks guys for helping me eliminating the vagueness I had. Looks like I'm still living the days and the experience of MQ6!
Last edited by yalmasri on Thu Nov 07, 2013 1:40 am; edited 1 time in total |
|
Back to top |
|
 |
yalmasri |
Posted: Thu Nov 07, 2013 12:05 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
Vitor wrote: |
You're going to get very confused and make this a lot harder than it needs to be for you if you cling to the concept of a cluster being a technological entity you can connect to when in fact it's a philosophical entity used to describe a workload pattern.
|
Then what do you call the sender/receiver channels and transmission queues that link the cluster nodes? I don't think these are philosophical things
Vitor wrote: |
And to correct you further, post WMQv7 (as has been pointed out more than once) you don't need to connect to a gateway queue manager, just to one of the participating queue managers. |
I'm actually confused; if we really can rely on one simple attribute to control message workload from outside the cluster, then what this link I originally sent is all about? It's still describing MQ7 |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Nov 07, 2013 4:21 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
yalmasri wrote: |
Vitor wrote: |
You're going to get very confused and make this a lot harder than it needs to be for you if you cling to the concept of a cluster being a technological entity you can connect to when in fact it's a philosophical entity used to describe a workload pattern.
|
Then what do you call the sender/receiver channels and transmission queues that link the cluster nodes? I don't think these are philosophical things |
Channels and transmission queues are specific things that you can create, modify, delete, monitor.
Show me the command to add a cluster. Or a command to modify a cluster. Or a command to monitor a cluster. Don't spend any effort on this because there are no commands against a cluster because there is no such 'thing' as an MQ cluster. You can't connect to an MQ Cluster - you connect to a Queue Manager (that might be a member of an MQ Cluster).
yalmasri wrote: |
Vitor wrote: |
And to correct you further, post WMQv7 (as has been pointed out more than once) you don't need to connect to a gateway queue manager, just to one of the participating queue managers. |
I'm actually confused; if we really can rely on one simple attribute to control message workload from outside the cluster, then what this link I originally sent is all about? It's still describing MQ7 |
Look at the pictures in the link you sent. They describe methods for getting messages to load balance when they come from outside the cluster, when they arrive from another queue manager that is outside the cluster. Your use case is different. Your messages are being produced by an MQ Client connected to a Queue Manager that is a member in the cluster. You messages were never on a QM outside of the cluster, so the link you originally posted does not apply to your use case. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vitor |
Posted: Thu Nov 07, 2013 6:03 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
yalmasri wrote: |
Then what do you call the sender/receiver channels and transmission queues that link the cluster nodes? |
I call them automatically created point to point links between 2 queue managers with an automatically managed transmission queue. There's nothing "cluster" about them. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|
|
|
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
|
|
|
|