| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| When to consider DEFCLXQ(CHANNEL) over DEFCLXQ(SCTQ)? |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQMB&WAS |
 Posted: Tue May 22, 2018 11:17 am Post subject: When to consider DEFCLXQ(CHANNEL) over DEFCLXQ(SCTQ)? |
 |
|
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 |
|
 |
| PeterPotkay |
| Posted: Wed Dec 11, 2019 6:39 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
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 |
|
|
| fjb_saper |
| Posted: Thu Dec 12, 2019 3:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
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 |
|
|
| GheorgheDragos |
| Posted: Mon Dec 30, 2019 12:16 pm Post subject: |
|
|
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 |
|
|
| eniomarques |
| Posted: Wed Feb 12, 2020 9:51 am Post subject: |
|
|
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
