| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Trigger Every on XMIT queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| bobbee |
 Posted: Tue Sep 18, 2012 3:45 pm Post subject: Trigger Every on XMIT queue |
 |
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
What would be the impact on z/OS of having a XMIT Queue Trigger set to EVERY. Would there be a process start attempted for every message that hits the XMIT queue. Obviously this would not work as there is an exclusive open on the XMIT queue but would this have a performance impact? Or does MQ understand what is going on and toss these messages if the channel has an open process against the XMIT queue?
I have a customer with performance issues and noticed this. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Sep 18, 2012 8:03 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
When the first message arrives on the triggered xmit queue, the channel initiator will attempt to start the channel. TRIGTYPE(FIRST) works perfectly. There is no need or benefit for TRIGTYPE(EVERY).
What performance issues?
_________________
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 |
|
|
| bobbee |
| Posted: Tue Sep 18, 2012 8:08 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
What happens when the 'other' messages show up on the XIT queue and MQ is told to send trigger messages to the INIT queue. What happens then? the CHIN is started already? What goes on. Does another CHIN get started and it fails because it cannot lock on the XMIT queue. All those processes starting and failing. Would seem to start degrading the system.
Yes, it is obvious and a BP to do First as the consuming app is designed for 'First' What happens when you configure it for EVERY. Not my configuration, it is the client. I told them not to do that, you will go blind. But they are arguing with me. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 18, 2012 8:37 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| bobbee wrote: |
| What happens when the 'other' messages show up on the XIT queue and MQ is told to send trigger messages to the INIT queue. What happens then? the CHIN is started already? |
WMQ for z/OS is different from WMQ on Win/UNIX. The qmgr executes in the MSTR address space; while the channels and listeners execute in the CHIN address space.
The CHIN address space is normally started just after the qmgr's MSTR address space starts. Listeners are started next.
Then the channels can start - either by op cmd, or by triggering.
| bobbee wrote: |
| What goes on. Does another CHIN get started and it fails because it cannot lock on the XMIT queue. All those processes starting and failing. Would seem to start degrading the system. |
Only one CHIN per qmgr. All that takes place when a msg arrives in the triggered xmit queue is that the channel will (attempt to) start.
| bobbee wrote: |
| Yes, it is obvious and a BP to do First as the consuming app is designed for 'First' What happens when you configure it for EVERY. Not my configuration, it is the client. I told them not to do that, you will go blind. But they are arguing with me. |
EVERY will cause a pointless, useless, needless trigger message to be written to the INITQ, which will cause needless START CHANNEL commands to be issued, which will receive a 'command issued' message in the CHIN sysout.
It's not worth an argument, really, as there is lots of horsepower on z hardware.
What performance issues does your client experience?
_________________
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.
Last edited by bruce2359 on Wed Sep 19, 2012 4:42 am; edited 2 times in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 18, 2012 8:38 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moving this to Mainframe forum.
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Sep 18, 2012 8:39 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Welcome to the dark side, Bobbee.
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Sep 18, 2012 8:45 pm Post subject: Re: Trigger Every |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| bobbee wrote: |
What would be the impact on z/OS of having a XMIT Queue Trigger set to EVERY. Would there be a process start attempted for every message that hits the XMIT queue. Obviously this would not work as there is an exclusive open on the XMIT queue but would this have a performance impact? Or does MQ understand what is going on and toss these messages if the channel has an open process against the XMIT queue?
I have a customer with performance issues and noticed this. |
Triggered xmit queues (contrasted with triggered app queues) cause a START CHANNEL command to be issued, so no app processes are started.
Issuing lots of START CHANNEL commands will not cause much overhead or other grief.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
