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 » Clustering » When to consider DEFCLXQ(CHANNEL) over DEFCLXQ(SCTQ)?

Post new topic  Reply to topic
 When to consider DEFCLXQ(CHANNEL) over DEFCLXQ(SCTQ)? « View previous topic :: View next topic » 
Author Message
MQMB&WAS
PostPosted: Tue May 22, 2018 11:17 am    Post subject: When to consider DEFCLXQ(CHANNEL) over DEFCLXQ(SCTQ)? Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

Hi,
Has anyone implemented the multiple xmitq per qmgr configuration? Does it improve performance or is it used just for isolation purposes? Are there any downsides inn using it, besides increasing the no.of queues to be monitored?
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Dec 11, 2019 6:39 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

We are considering it going forward. I am researching posts about it. I was happy to find your post, and sad to see no replies.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Dec 12, 2019 3:17 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

I believe the main reason for doing this is to simplify error tracking.
If you use the SCTQ you first have to check the SCTQ to find what qmgr is affected.

Also if would avoid affecting all qmgrs in the cluster should the SCTQ become full, because now you have one XMITQ per qmgr...

Most of the time the reason you see a cluster XMITQ growing is:
  • There is a queue full on the destination queue manager
  • messages cannot be delivered to another cluster qmgr
    Either because the qmgr is the only one hosting the queue
    Or the app did not open the queue correctly
  • There is a network problem between source and destination qmgr

Hope it helps
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
GheorgheDragos
PostPosted: Mon Dec 30, 2019 12:16 pm    Post subject: Reply with quote

Acolyte

Joined: 28 Jun 2018
Posts: 51

We do not have this in our installation, however, for standardization, ease of follow up, to avoid full XMIT queues, and to remove the old days manually defined 1 XMITQ per App, we are taking in consideration. We run a QSG though, not a cluster. I see no reasons why the performance should be degraded ( depending on what sort of triggering you will use though, for EVERY, depending on the size of your installation, it might generate a little overhead. )

Dragos Gheorghe
Back to top
View user's profile Send private message
eniomarques
PostPosted: Wed Feb 12, 2020 9:51 am    Post subject: Reply with quote

Novice

Joined: 25 May 2015
Posts: 24
Location: Brazil

We have it in some of our QMs, and we couldn't notice any performance improvement (avg response times are pretty much the same), but it's good for troubleshooting. We had some sporadic queuing in the SCTQ due a network latency which was hard to determine the source, and was easily pointed when it was split per channel.
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 » Clustering » When to consider DEFCLXQ(CHANNEL) over DEFCLXQ(SCTQ)?
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.