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 » Mainframe, CICS, TXSeries » Rolled back message NOT getting re-triggered

Post new topic  Reply to topic Goto page Previous  1, 2
 Rolled back message NOT getting re-triggered « View previous topic :: View next topic » 
Author Message
bob_buxton
PostPosted: Thu Sep 15, 2005 1:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
wschutz
PostPosted: Thu Sep 15, 2005 2:08 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail AIM Address
PeterPotkay
PostPosted: Thu Sep 15, 2005 2:32 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
wschutz
PostPosted: Thu Sep 15, 2005 2:38 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail AIM Address
jefflowrey
PostPosted: Thu Sep 15, 2005 5:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Thu Sep 15, 2005 6:08 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
MQ_Matt
PostPosted: Mon Sep 19, 2005 10:50 am    Post subject: Reply with quote

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
View user's profile Send private message
wschutz
PostPosted: Mon Sep 19, 2005 11:22 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail AIM Address
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Rolled back message NOT getting re-triggered
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.