| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Bind to Specific, known instance of a clustered queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| Paul D |
 Posted: Fri Nov 30, 2007 2:28 pm Post subject: Bind to Specific, known instance of a clustered queue |
 |
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
I have a scenario that I'd like some help in solving. I have a client on one queue manager (A) and two instances of a service, one on queue manager (B) and another on queue manager (C). My setup is to have an non-clustered alias on QM (A) named REQUEST with a base QName of REQUEST. The client puts request messages to this queue REQUEST, and these get distributed to the local clustered request queues on (B and C). So, on B and C, there are clustered local queues of the name REQUEST, producing ~ 50/50 distribution of request messages. Pretty standard stuff.
Here is my issue, at some points, I'd like to direct a message from the client to a specific instance of the service request queue, either on QM (B) or QM (C). I want to make sure it only goes to that side, or "bind" to a specific side, as directed in the client's code. I'd also like to use the same clustered local queue that the service is already listening on, not a new one. As stated before, the client must be able to "pick" which side he wants to send the request to in this scenario. The client can use a different queue def to put to when he sends it, that is not an issue, but we'd want the service to still be listening to the same, single clustered request queue (i.e. REQUEST). Is this possible?
I did some tests with alias queues on the B and C sides to resolve to this local request queue, but that did not work consistently. Can remote queues help with this? Any other ideas? I'd like to not try and introduce an additional queue on the service side to listen on for this.
_________________
Thanks!!!
Paul D |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Nov 30, 2007 3:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If you defined a remote queue REQUESTB/C that named the clustered queue REQUEST and the remote queue manager (B/C) that ought to do it. The actual message would still traverse the cluster without additional channels.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 30, 2007 3:49 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm a little confused...
Why is BIND_ON_OPEN not an option here?
Also, remember that responses will always go to ReplyToQueue on ReplyToQueue manager, so there should never be any cluster resolution going on there (and no reason to share the replytoqueue in the cluster, either).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 30, 2007 9:20 pm Post subject: Re: Bind to Specific, known instance of a clustered queue |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Paul D wrote: |
| My setup is to have an non-clustered alias on QM (A) named REQUEST with a base QName of REQUEST. |
That's kinda pointless, no?
| Paul D wrote: |
| Here is my issue, at some points, I'd like to direct a message from the client to a specific instance of the service request queue, either on QM (B) or QM (C). I want to make sure it only goes to that side, or "bind" to a specific side, as directed in the client's code. I'd also like to use the same clustered local queue that the service is already listening on, not a new one. As stated before, the client must be able to "pick" which side he wants to send the request to in this scenario. The client can use a different queue def to put to when he sends it, that is not an issue, but we'd want the service to still be listening to the same, single clustered request queue (i.e. REQUEST). Is this possible? |
Simply have the putting app specify QMB or QMC in the MQOD_ObjectQmgrName field on the MQOPEN or MQPUT1 call while specifying REQUEST for the MQOD_ObjectName. You don't need any additional q defs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Paul D |
| Posted: Mon Dec 03, 2007 7:25 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
Thanks for your comments. The bind_on_open is not an option in some of my cases. We have an old proprietary MQ framework that was put in place before clustering was used and that is not exposed. Due to this, using that would be more costly to implement. I was looking for something less invasive.
Specifying the QM on the open (I call it a "remote put") requires permissions on the transmit queue, which violates our security policy, apps need to talk to local objects so we can apply security there. Hence the reason for my discussion of the alias queue approach. This is our typical clustering setup. Clustered queues are fronted by the local alias queues.
The remote to local queue solution will work. An additional question. So when that remote queue is pointing to a clustered local queue, is there any way for the message to get resolved back to the cluster? Yes or No. Is this true even that if the clustered local queue would get put disabled (assume on purpose by the service provider that owns that queue). Could we just get the put fail as the desired result?
Another related followup question to this. Say the client and service are running on the same box. As the client, I want to put a message to the local service instance on my same queue manager and again want only that program listening locally on that queue to pick it up. Remember that this is a local clustered queue. How can I do that? In my situation, would going to bind_on _open be my only option? Any other options. Things to watch out for?
_________________
Thanks!!!
Paul D |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 03, 2007 7:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You don't say if you're on v5.3 or v6. If you're on v5.3 and there's a locally hosted copy of a clustered queue the message will always go there.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Paul D |
| Posted: Mon Dec 03, 2007 7:41 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
We are on v6. Whout about the clustered workload setting of (CLWLUSEQ)? If that is turned into to "Any", we could go to the other instances, correct? Also, of it's set to "local", then if that queue is put disabled, won't we go to the other side also automatically?
_________________
Thanks!!!
Paul D |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Dec 03, 2007 7:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the qremote specifies both rqname and rqmname, then these will be resolved on the local qmgr to determine where to send.
When the message arrives on the rqmname qmgr, then they will be re-resolved to find out if any multi-hopping needs to be done.
CLWLUSEQ(QMGR) on the destination qlocal(s) can ensure that messages sent from client connected to QMGR A will be put to the qlocal on QMGRA first, rather than through the cluster.
This would be picked up during cluster name resolution - when the qalias/qremote is being looked up.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 03, 2007 7:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Paul D wrote: |
| If that is turned into to "Any", we could go to the other instances, correct? |
AFAIK
| Paul D wrote: |
| Also, of it's set to "local", then if that queue is put disabled, won't we go to the other side also automatically? |
NAFAIK. They'll wait for the queue to be reenabled because their target is fixed.
I'll stand to be corrected on that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Paul D |
| Posted: Wed Dec 05, 2007 2:03 pm Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
In regards to this...
| Quote: |
| Also, of it's set to "local", then if that queue is put disabled, won't we go to the other side also automatically? |
I tested it out on MQ v6. If the local clustered queue set to usage local and if we put disable it, messages will be routed over to the other available instances. This is true for both a remote coming into that queue (re-resolved) or if the put was done locally on the same queue manager. The put disable does NOT override the clustering algorithm, in only takes this local instance out of consideration. In my case, I need to tell my developers that put disabling the queue will turn off that instance but will route ALL messages to that instance to other availaable instances in all cases.
_________________
Thanks!!!
Paul D |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 06, 2007 1:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I am elightened and I thank you for your experimentation 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
