| Author |
Message
|
| paleyplease |
 Posted: Tue Aug 29, 2017 11:17 am Post subject: Multiple System Cluster Transmit Queue Issue |
 |
|
Apprentice
Joined: 05 Feb 2014
Posts: 45
|
6 QMGRs in a cluster where 2 are producers or putters, which can send to 4 downstream QMGRs which are all multi instance.
I updated the value on the 2 producer QMGRs DEFCLXQ to "CHANNEL", however I only see 3 new SCTQ.QMGR<A/B/C> created, but the 4th downstream still uses the existing SCTQ. I am wondering why not all 4 are using their own SCTQs.
Any help. |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Tue Aug 29, 2017 11:37 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Is it possible you just haven't waited long enough? MQ will only make the change once the queue is empty or suspended with no in-flight messages I believe.
Do you use CLCHNAME ?
Cheers,
Paul
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| paleyplease |
| Posted: Tue Aug 29, 2017 11:47 am Post subject: |
|
|
Apprentice
Joined: 05 Feb 2014
Posts: 45
|
| I did make this change a good 2 weeks back. I even noticed the Dynamically created cluster sdr chls go in active due to no volume. I blasted some msgs via the sample program but still the 4th and final qmgrs SCTQ didnt get created. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Aug 29, 2017 11:57 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Is it possible you have some uncommitted messages on the queue ? What is the result of DIS QSTATUS(SCTQ) UNCOM ?
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 29, 2017 1:44 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
My preference is never to let the queue manager auto-define cluster transmission queues, especially in such a small cluster like you have. From the outset I define a 'static' cluster transmission queue first (along the lines of CLUSTERNAME.QMGRNAME, e.g. RETAIL.+QMNAME+) and ensure the channel name pattern in the CLCHNAME of the XMITQ is CLUSTERNAME.*
About the only time I do let queue managers do it themselves is if large persistent messages are going across the channels, and then I make damn sure that the CLUSRCVRs on the other end have a very small batch size, and preferably that size is 1 (one), otherwise I don't really see the utility in having multiple cluster transmission queues.
And I'm happy to debate the pros and cons of all views 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 29, 2017 6:32 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
It might make sense if a qmgr is auto-created and launched as a service - to meet a sudden and dramatic increase in requests.
Not to be too cynical here, but a sudden and dramatic increase in requests might be viewed as not understanding workload and/or poor planning for it. So, its a pro, and it's a con - a procon.
_________________
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 |
|
|
| rammer |
| Posted: Tue Aug 29, 2017 11:02 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| What vewrsion of MQ is it, there was a bug for this in 7.5 fixed by later patches... |
|
| Back to top |
|
|
| vinay.gollapalli |
| Posted: Wed Aug 30, 2017 4:56 am Post subject: Re: Multiple System Cluster Transmit Queue Issue |
|
|
Novice
Joined: 22 Aug 2017
Posts: 22
|
| paleyplease wrote: |
6 QMGRs in a cluster where 2 are producers or putters, which can send to 4 downstream QMGRs which are all multi instance.
I updated the value on the 2 producer QMGRs DEFCLXQ to "CHANNEL", however I only see 3 new SCTQ.QMGR<A/B/C> created, but the 4th downstream still uses the existing SCTQ. I am wondering why not all 4 are using their own SCTQs.
Any help. |
What is the status of dis clusqmgr ? |
|
| Back to top |
|
|
| paleyplease |
| Posted: Wed Aug 30, 2017 7:32 am Post subject: |
|
|
Apprentice
Joined: 05 Feb 2014
Posts: 45
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 30, 2017 9:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I seem to recall testing this at 9.0.0.0. Gosh, how long ago was that?
You might want to look at the max outbound cluster channel setting. Run this mqsc command
DISPLAY QMGR CLWLMRUC
Post the results here.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Wed Dec 11, 2019 6:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| exerk wrote: |
My preference is never to let the queue manager auto-define cluster transmission queues, especially in such a small cluster like you have. From the outset I define a 'static' cluster transmission queue first (along the lines of CLUSTERNAME.QMGRNAME, e.g. RETAIL.+QMNAME+) and ensure the channel name pattern in the CLCHNAME of the XMITQ is CLUSTERNAME.*
About the only time I do let queue managers do it themselves is if large persistent messages are going across the channels, and then I make damn sure that the CLUSRCVRs on the other end have a very small batch size, and preferably that size is 1 (one), otherwise I don't really see the utility in having multiple cluster transmission queues.
And I'm happy to debate the pros and cons of all views |
exerk,
A couple years later, still the same thoughts regarding DEFCLXQ versus CLCHNAME vs everything just using SYSTEM.CLUSTER.TRANSMIT.QUEUE?
What benefit do you see predefine the XMITQs versus letting the QM define them?
With our move to MQ 9.1, I am considering moving to DEFCLXQ. To date we have always relied on a single SYSTEM.CLUSTER.TRANSMIT.QUEUE per QM. No issues rely with that. I think trouble shooting might be easier if there is a separate XMITQ to each QM. For example, if we get an alert for old messages on a cluster XMITQ, it will be easier and faster to understand the impact.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 11, 2019 10:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| A couple years later, still the same thoughts regarding DEFCLXQ versus CLCHNAME vs everything just using SYSTEM.CLUSTER.TRANSMIT.QUEUE?... |
Yes for small clusters, but I may have to review that for big ones!
| PeterPotkay wrote: |
| ...What benefit do you see predefine the XMITQs versus letting the QM define them?... |
It's about control in small clusters (I can be very retentive!), but what I don't like about DEFCLXQ is that all names start with SYSTEM. I have yet to try my hand at trying to redefine the model queue used.
| PeterPotkay wrote: |
| ...With our move to MQ 9.1, I am considering moving to DEFCLXQ. To date we have always relied on a single SYSTEM.CLUSTER.TRANSMIT.QUEUE per QM. No issues rely with that. I think trouble shooting might be easier if there is a separate XMITQ to each QM. For example, if we get an alert for old messages on a cluster XMITQ, it will be easier and faster to understand the impact. |
I 'campaigned' for separate cluster transmission queues (for many of the reasons you state above), so was extremely glad to see them introduced as I was never comfortable with the 'one queue to rule them all' scenario.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 11, 2019 11:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
thanks exerk
I'm leaning towards giving it a go with DEFCLXQ. The names of the auto defined XMITQs can be predicted so my monitoring policies can be tuned to find them as they appear.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
