| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Rolled back message NOT getting re-triggered |
« View previous topic :: View next topic » |
| Author |
Message
|
| bob_buxton |
 Posted: Thu Sep 15, 2005 1:42 pm Post subject: |
 |
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Rolling back messages onto a queue does not cause a new trigger message to be generated.
Last close of a queue that still has messages on it in will cause a trigger message to be generated.
Bob
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
 |
| wschutz |
| Posted: Thu Sep 15, 2005 2:08 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Bob, the question at play was if the only message on a queue was gotten under syncpoint and the UOW was still not committed when the queue was closed, would that message count in the triggering decision? Based on the beviour described here, it appears not to be the case.
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 15, 2005 2:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| wschutz wrote: |
| Bob, the question at play was if the only message on a queue was gotten under syncpoint and the UOW was still not committed when the queue was closed, would that message count in the triggering decision? Based on the beviour described here, it appears not to be the case. |
Sure, and that agrees with the manuals.
A trigger message is generated when the message hits the queue, and all those other conditions are met. But the trigger message is not committed until the application message is EITHER committed or rolled back.
The queue is closed, but the message is not committed, so neither is the trigger message. Once the message is committed, or rolled back, either before or after the MQCLOSE, then the trigger message, if present, is released.
That section in the manual on triggering is big, but could be bigger. When a trigger message is generated by the QM, and when the trigger message is consumed by the trigger monitor are 2 completly separate events each with their own rules. The manuals don't get into that enough (at all?), IMHO.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Sep 15, 2005 2:38 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Peter, what you're describing is the logic around the MQPUT. This scenario was related to re-triggering subsequent to an MQGET, which afaik, isn't documented at all.
To recap, this does not cause re-triggering:
MQGET with SYNCPOINT
MQCLOSE
MQBACK
...where-as this does:
MQGET with SYNCPOINT
MQBACK
MQCLOSE (trigger event happens here)
EDIT: I just did a quick test and this is also the behaviour on the distributed qmgrs.
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 15, 2005 5:02 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Giving the benefit of the doubt to the sourcecode...
If MQGET, MQCLOSE, MQBACK is performed and everything works properly, I would think that ipprocs would be 0 when curdepth went from 0 to 1.
Likewise, MQGET, MQBACK, MQCLOSE means that ipprocs is 1 when curdepth goes from 0 to 1.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 15, 2005 6:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| I would never expect a rollback, with a trigtype=FIRST, to retrigger, myself. The queue depth never changes until a GET is committed. |
I just tested this with a VB.NET 5.3.0.10 MQClient doing an MQGET with SYNCPOINT_YES from a z/OS 5.3 Queue Manager.
The queue depth does go to zero when that message is gotten off of the queue, even before it is committed.
*****Trigger Yes
MQGET with SYNCPOINT
MQBACK
MQCLOSE (trigger event happens here)
********
Yup, because at the MQCLOSE, the q depth is > 0, and that satisfies the trigger conditions.
********No trigger
MQGET with SYNCPOINT
MQCLOSE
MQBACK
******************
Yup! Because at MQCLOSE time, the q depth is 0. Why doesn't the trigger fire when the message is backed out? Because MQBACKing a message to a queue, causing the depth to go from 0-1 is not the same as MQPUTing a message to a queue, causing the depth to go from 0-1.
I guess you have to take Rule #1 in the Trigger conditions quite literally!!!
| Quote: |
1. A message is put on a queue.
|
PUT, not backed out!
So even though the depth rises from 0-1 on this triggered q, the QMs trigger logic is probably not driven because an MQPUT was not issued against this queue. But it probably should be driven, even by an MQBACK.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQ_Matt |
| Posted: Mon Sep 19, 2005 10:50 am Post subject: |
|
|
Novice
Joined: 14 Sep 2005
Posts: 10
Location: Toronto
|
I believe condition 12 from the manual covers off what I've been experiencing:
| Quote: |
12. The only application serving a queue issues an MQCLOSE call, for a TriggerType of MQTT_FIRST or MQTT_DEPTH, and there is at least:
- one (MQTT_FIRST)
or
- TriggerDepth (MQTT_DEPTH
messages on the queue of sufficient priority (condition 2) and conditions 6 through 10 are also satisfied.
This is to allow for a queue server that issues an MQGET call, finds the queue empty, and so ends; however, in the interval between the MQGET and MQCLOSE calls, one or messages arrive.
Notes:
1. If the program serving the application queue does not want to retrieve all messages, this can cause a closed loop. Each time the program closes the queue, the queue manager creates another trigger message which causes the trigger monitor to start the server program again.
2. If the program serving the application queue backs out its get request (or if the program abends) before it closes the queue, the same happens.
3. To prevent such a loop occurring, you could use the BackoutCount field of MQMD to detect messages that are repeatedly backed out. For more information, see Messages that are backed out. |
The key item being Note 2, where it is indicated that a closed loop will occur if a Get request is backed out before the monitored queue is closed.
Preventing re-triggering by closing the monitored queue before a rollback is contingent, I think, on there being only 1 message on the monitored queue. Otherwise Note 1 kicks in. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Sep 19, 2005 11:22 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| Preventing re-triggering by closing the monitored queue before a rollback is contingent, I think, on there being only 1 message on the monitored queue. Otherwise Note 1 kicks in. |
I would think its a function of whether or not there are any messages that are not in the uncommitted (from MQGET) state....
_________________
-wayne |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
