| Author |
Message
|
| sumit |
 Posted: Fri Apr 03, 2009 5:52 am Post subject: CLWL use queue |
 |
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
HI,
If we set CLWLUSEQ paratmeter as 'Local' on a queue or a queue manager, then the messages will deliver to local instance (local to application) of queue.
Question is, if the application wants to put message in local queue then what is the need to define a queue (with same name and shared to cluster) on another queue manager under same cluster? The application will never use the cluster instance of local queue.
And if we have to use default value i.e. 'any' at queue manager or queue level, then what is the use of this property?
I can't think of a scenario except where multiple applications need to access same queue in different time frame. And the application will switch the queue property as per the requirement.
Can you please present a feasible or working scenario so that I can understand the practicle use of this property? 
_________________
Regards
Sumit |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Apr 03, 2009 6:15 am Post subject: Re: CLWL use queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
| And if we have to use default value i.e. 'any' at queue manager or queue level, then what is the use of this property? |
You don't have to use it at queue level. It's a choice.
| sumit wrote: |
| Can you please present a feasible or working scenario so that I can understand the practicle use of this property? |
You have WMQv6 queue managers in a cluster with WMQv5.3 queue managers and you want them to behave the same.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Apr 03, 2009 6:27 am Post subject: Re: CLWL use queue |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| Vitor wrote: |
| sumit wrote: |
| And if we have to use default value i.e. 'any' at queue manager or queue level, then what is the use of this property? |
You don't have to use it at queue level. It's a choice.
|
Right, but that's the default setting. So if I have to use 'Local', then there is no need for me to creat a cluster instance of local queue on another queue manager. Then why would I even expose this local instance of queue to cluster?
| Vitor wrote: |
| sumit wrote: |
| Can you please present a feasible or working scenario so that I can understand the practicle use of this property? |
You have WMQv6 queue managers in a cluster with WMQv5.3 queue managers and you want them to behave the same. |
Vitor, can you please elaborate?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 03, 2009 6:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Read the MQ Cluster Manual's section on this attribute again. You are missing the point.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Apr 03, 2009 7:11 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Quote from clustering pdf:
| Quote: |
| This queue attribute specifies the behavior of an MQPUT operation when the target queue has a local instance and at least one remote cluster instance (except where the MQPUT originates from a cluster channel). This parameter is valid only for local queues. If you specify QMGR, the behavior is as specified by the CLWLUSEQ parameter of the queue manager definition. If you specify ANY, the queue manager treats the local queue as another instance of the cluster queue for the purposes of workload distribution. If you specify LOCAL, the local queue is the only target of the MQPUT operation. |
| PeterPotkay wrote: |
| Read the MQ Cluster Manual's section on this attribute again. You are missing the point. |
Do you mean to say I missed this!!
| Quote: |
| (except where the MQPUT originates from a cluster channel) |
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 03, 2009 9:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Read the MQ Cluster Manual's section on this attribute again. You are missing the point. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sumit |
| Posted: Wed Apr 08, 2009 2:44 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| Vitor wrote: |
| PeterPotkay wrote: |
| Read the MQ Cluster Manual's section on this attribute again. You are missing the point. |
|
I am seriously missing something and am still looking into the docs and infocenter for more info. 
For the time being, can you please present a (plausible or practical) scenario where we can use this property?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 08, 2009 3:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Look at the difference of a cluster with / without a gateway qmgr... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sumit |
| Posted: Thu Apr 09, 2009 6:41 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| sumit wrote: |
I am seriously missing something and am still looking into the docs and infocenter for more info. |
I can find 66 search results in google for CLWLUSEQ (although it shows some 370 results count in first page but doesn't show anything after page 7). Clicked on nearly all the links which I could relate with my problem. But, I am still there and thinking.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 09, 2009 6:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
| I am still there and thinking. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 09, 2009 6:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Your original question has an entirely backwards understanding of MQ Clustering.
MQ Clustering provides no mechanism for an application to GET messages from remote queues.
CLWLUSEQ therefore, like all other cluster parameters, only applies to messages that are PUT.
The only way your original scenario "makes sense" is if you have exactly one instance of exactly one application sending messages to exactly one instance of exactly one other application. Then, yes, there's no reason to share the receiving queue in the cluster, because there will never be anything that is going to read from that other queue. And there's no reason to change CLWLUSEQ to anything other than the default, because there's only one instance of the receiving queue at all.
But that scenario has no use of clustering at all. So to ask about it in relation to CLWLUSEQ is missing the point. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 09, 2009 6:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
In my early days with MQ, I stenciled PUT GLOBAL, GET LOCAL in my shorts, just as a reminder.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 09, 2009 7:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| I stenciled PUT GLOBAL, GET LOCAL in my shorts |
More information than I needed!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sumit |
| Posted: Thu Apr 09, 2009 7:21 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| mqjeff wrote: |
| Your original question has an entirely backwards understanding of MQ Clustering. |
Might be.
| mqjeff wrote: |
MQ Clustering provides no mechanism for an application to GET messages from remote queues.
CLWLUSEQ therefore, like all other cluster parameters, only applies to messages that are PUT. |
I understand that and I never mentioned that I am want to use Cluster for GET operation.
| mqjeff wrote: |
| The only way your original scenario "makes sense" is if you have exactly one instance of exactly one application sending messages to exactly one instance of exactly one other application. Then, yes, there's no reason to share the receiving queue in the cluster, because there will never be anything that is going to read from that other queue. And there's no reason to change CLWLUSEQ to anything other than the default, because there's only one instance of the receiving queue at all. |
Let me explain my 'hypothetical' scenario again.
Suppose 2 qmgrs (not FP) QM1 and QM2 are in cluster and have a localq defined L1 which is shared to cluster. Now there are 2 application on same server as QM1, App1 and App2. App1 works during morning and App2 during night (without any overlap). Because of some hypothetical requirement App1 needs to put msgs only in L1 of QM1. Then it can set CLWLUSEQ as 'Local' and finishes it's work. App2 doesn't have any constraint and hence first set CLWLUSEQ as 'ANY' (for load balancing) and then puts messages on L1 queue which will deliver to destination.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 09, 2009 7:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
| Because of some hypothetical requirement App1 needs to put msgs only in L1 of QM1. |
Then it should specify QM1.L1, bypass the workload balancing and thus the setting of CLWLUSEQ is irrelevent.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
