| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Different behavior for 'trigger first' and 'trigger interval |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Mon Oct 09, 2006 5:53 am Post subject: Different behavior for 'trigger first' and 'trigger interval |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
From the MQ list serve:
| Quote: |
I've spoken to the lead z/OS local queue manager developer about this. In response to a customer reported problem, the v6 z/OS QMgr code was changed so that the generation of (re-)trigger messages is no longer dependent on another message arrving. To see why, here is some of the defect text:
"The design point for queue sharing groups assumed that QSGs would be symmetrical. As customers become more mature we are seeing a growth of asymmetric QSGs where a subset of qmgrs are treated as work providers (putters) and another subset are treated as work consumers.
In a particular scenario inbound messages can come from all/any QMgrs in the QSG via channels, but only 2 QMgrs run the processing CICS regions with associated CKTI trigger monitors.
Due to application problems (identified), trigger messages were being thrown away, but the backstop trigger interval mechanism was not correctly generating TriggerInterval events which would have saved the situation.
Underlying cause is that in a QSG, TriggerInterval messages are created by Putters. However, in this environment, there are no putters running on the systems where trigger monitors are running, so they did not detect that it was necessary to create TriggerInterval events."
The new implementation means that trigger messages are generated in a more timely fashion for both local and shared queues.
The code change was made late in the devlopment cycle for V6 and unfortunately the documentation update got missed. I will raise a defect to get this addressed for the next release of the documentation.
Russell
Russell Finn
MQSeries System Test
(removed Russell's email, since he did not intend for it to be displayed on some website where a spammer could get it)
|
If a q is set to trigger on first, that means a trigger message will only be generated if the q depth goes from 0 to 1. It is possible that a triggered on first q might find itself with greater than 0 messages with no process running, and as more messages arrive, there would be no triggering, since the depth is not going from 0 to 1.
The Queue Manager's Trigger Interval attribute helps get around that. We have ours set to 60000 milliseconds, or 1 minute. What that means is that if Trigger Interval has passed (1 minute in our case), AND another message lands, go ahead and trigger anyway, even though the q is no longer going from 0 to 1. Note the requirement for BOTH the time interval passing and an additional message arriving.
This is the way it has worked on mainframe and distributed (Windows, Solaris, Linux, etc) forever.
In MQ 6.0, it still works this way on distributed QMs. But it has changed for MQ 6.0 on the mainframe. On MQ 6.0 on the mainframe, a new trigger message will be generated every Trigger Interval milliseconds, as long as the the q is > 0, WITHOUT needing another message arriving. This is a positive change in my opinion, since it is more intuitive. Hopefully distributed MQ will be this way soon too.
Note that the documentation is lagging behind, and this distinction is not yet in the manuals.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Mon Oct 09, 2006 7:28 am; edited 1 time in total |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Mon Oct 09, 2006 7:22 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| It is possible that a triggered on first q might find itself with greater than 0 messages with no process running |
How is this possible within the trigger rules?
If the triggered app leaves msgs on the queue, then when the queue is closed a trigger msg is generated.
if the triggered app clears the queue, then the next msg to arrive on the queue will generate a trigger msg, either if the msg is put before the queue is closed, as above, or after the queue is closed in the usual way.
What did I miss?
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 09, 2006 7:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Message #1 lands on triggered q.
Depth goes from 0 to 1.
Trigger fires.
Triggered app starts. Prior to opening the queue, it is supposed to connect to a database. The database is temporarlily N/A, so the app ends. (Hey, I didn't write it)
The triggered queue is now > 0, thru no fault of MQ. Without Trigger Interval, AND more messages, we are S.O.L.
On MQ 6.0 z/OS, we only need Trigger Interval (and not more messages) to auto try again (retrigger).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Oct 10, 2006 12:27 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Got it.
The app never opens the queue, so the trigger on close rule (12) is not invoked.
_________________
MQSeries.net helps those who help themselves.. |
|
| 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
|
|
|
|
