ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Multiple System Cluster Transmit Queue Issue

Post new topic  Reply to topic
 Multiple System Cluster Transmit Queue Issue « View previous topic :: View next topic » 
Author Message
paleyplease
PostPosted: Tue Aug 29, 2017 11:17 am    Post subject: Multiple System Cluster Transmit Queue Issue Reply with quote

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
View user's profile Send private message
PaulClarke
PostPosted: Tue Aug 29, 2017 11:37 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
paleyplease
PostPosted: Tue Aug 29, 2017 11:47 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulClarke
PostPosted: Tue Aug 29, 2017 11:57 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
exerk
PostPosted: Tue Aug 29, 2017 1:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Aug 29, 2017 6:32 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9392
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
View user's profile Send private message
rammer
PostPosted: Tue Aug 29, 2017 11:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
vinay.gollapalli
PostPosted: Wed Aug 30, 2017 4:56 am    Post subject: Re: Multiple System Cluster Transmit Queue Issue Reply with quote

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
View user's profile Send private message
paleyplease
PostPosted: Wed Aug 30, 2017 7:32 am    Post subject: Reply with quote

Apprentice

Joined: 05 Feb 2014
Posts: 45

Its version 8.0.0.7
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Aug 30, 2017 9:04 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9392
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
View user's profile Send private message
PeterPotkay
PostPosted: Wed Dec 11, 2019 6:26 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
exerk
PostPosted: Wed Dec 11, 2019 10:18 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Wed Dec 11, 2019 11:31 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Multiple System Cluster Transmit Queue Issue
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.